LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 12-28-2008, 08:21 PM   #1
davidlandy
LQ Newbie
 
Registered: Dec 2008
Posts: 3

Rep: Reputation: 0
32k Blocksize Support


I'm trying to upgrade the hard drive in my PVR, without losing all my existing recordings.

The trouble is, the data partition on the drive is in Ext2 format, but with 32k blocks -- so it can't be mounted in Linux, and the standard partition resizing tools won't touch it (they say it has an invalid superblock).

I've managed to copy the entire old drive (80gb) to a correctly-formatted new drive (160gb) using dd, and then restored the partition table correctly (again with dd). The disk works fine, but it looks like an 80gb drive to the PVR as the superblock etc are still set for 80gb.

Can anyone think of a workaround for this problem? Are there any partition resizing tools that will touch 32k-block partitions? Has anyone seen a tool that will fix up the superblock and sector allocation tables? Could anyone write one?

Any help would be much appreciated.

David

Last edited by davidlandy; 12-28-2008 at 08:26 PM.
 
Old 12-28-2008, 10:18 PM   #2
i92guboj
Gentoo support team
 
Registered: May 2008
Location: Lucena, Córdoba (Spain)
Distribution: Gentoo
Posts: 4,063

Rep: Reputation: 381Reputation: 381Reputation: 381Reputation: 381
According to the kernel documentation (and I don't think anyone else has the right to say what's ext2 and what isn't), the blocks in an ext2 fs have a size of 1024, 2048 or 4096 bytes. In Alpha system they can get as big as 8192 bytes. Anything else is not ext2 even if the manufacturer claims so. At least that's my understanding.

The problem won't be the tools. Most of them should allow you to format using whatever block size you want, but you will not be able to mount them just because the kernel won't support it. You might want to check the linux kernel mailing lists for patches to increase the block size. They appear every now and then but I don't know why do they not get merged into the stable branch. In other words, if you want support for this you are going to have to patch the kernel.

You could as well try to just reformat the drive with a sane ext2 file system. Of course you will lose everything inside that drive.
 
Old 12-29-2008, 03:27 AM   #3
davidlandy
LQ Newbie
 
Registered: Dec 2008
Posts: 3

Original Poster
Rep: Reputation: 0
Thanks for that.

Just to be clear, are you saying that the resizing tools all use the kernel to access the fs and therefore will all fail without a patched kernel? Or do (at least some of them) do their own jiggery-pokery behind the scenes and therefore may work (or be patched to work) without a patched kernel?

It would be good to know - though both approaches may of course work independently.

For example, I have considered writing some code to manually fix the fs myself (not too hard as all the new space is empty, so no inode stuff to write, only block allocation bitmaps and maybe some new file groups). This wouldn't require patching the kernel, and could use dd to patch the affected parts of the drive. A bit brutal, I must admit, but it would (just might!) work.

The trouble is I'm a *nix noob and though I have a lot of experience on the MS platform and with VB, I have only a little knowledge of *nix and C, so it would be a bit of an inelegant solution, to say the least! (Like, port the relevant parts of the drive to a FAT32 partition, manipulate them with VB, output a set of patches to be applied by dd under Linux. Yuck!! But it could work...)

And, rather than re-invent the wheel, I thought someone with more Linux/C experience might have been down this path before - or be willing to spend a little time on a possible solution...

However, I will take your hint and resuccitate my attempts to persuade my favourite Linux distro to include Christoph Lameter's patchset (with 32k blocksize support) in their next release - one issue is that the patchset still needs some work, I believe, which is beyond me both technically and in terms of the work it would require. (I'd be far better off writing my inelegant solution, described above, for example.)

Has anyone had any success in compiling a kernel with 32k blocksize support, or know of anything re-distributable that has worked?

Thanks again for any help.

David
 
Old 12-29-2008, 03:37 AM   #4
i92guboj
Gentoo support team
 
Registered: May 2008
Location: Lucena, Córdoba (Spain)
Distribution: Gentoo
Posts: 4,063

Rep: Reputation: 381Reputation: 381Reputation: 381Reputation: 381
Quote:
Originally Posted by davidlandy View Post
Thanks for that.

Just to be clear, are you saying that the resizing tools all use the kernel to access the fs and therefore will all fail without a patched kernel? Or do (at least some of them) do their own jiggery-pokery behind the scenes and therefore may work (or be patched to work) without a patched kernel?
Technically, it's possible to do that kind of stuff without any support on the kernel side. It's all about picking a block device (a file after all) and changing its internal format a bit.

You could check parted, there's a good chance that it can do what you want.

However, you will not be able to mount it in linux without kernel-side support, unless someone designs an ext2 FUSE driver that has this feature (I don't know of such a thing).

Quote:
For example, I have considered writing some code to manually fix the fs myself (not too hard as all the new space is empty, so no inode stuff to write, only block allocation bitmaps and maybe some new file groups). This wouldn't require patching the kernel, and could use dd to patch the affected parts of the drive. A bit brutal, I must admit, but it would (just might!) work.
Possible, yes. debugfs could come in handy as well. However, make sure you have a backup of the whole partition (I guess you already have it) before doing such a thing.

To sum up: if you are not going to mount the fs under linux, you don't need to patch the kernel for anything. However, being able to mount it, even if it's just for test purposes, is a handy thing to have if you plan to debug the fs at low level.
 
Old 12-29-2008, 03:48 AM   #5
davidlandy
LQ Newbie
 
Registered: Dec 2008
Posts: 3

Original Poster
Rep: Reputation: 0
Thanks very much for clearing that up - and for the tip re debugfs, I'll certainly follow that up.

Good advice too re making a backup, I've been relying on having the original disk from the PVR but I suppose that might get damaged or accidentally overwritten so it'd be smart to make a backup.

 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Understanding blocksize noir911 *BSD 1 04-25-2008 08:30 AM
What is blocksize? binarybob0001 Linux - Software 6 04-21-2006 08:27 PM
nfs problem with files > 32k bruno buys Linux - Networking 2 05-02-2005 05:37 PM
my reiser raid0 benchmarks for 32K and 64K chunk sizes hedpe Linux - Hardware 1 04-14-2005 03:44 AM
Recompiling RH 7.1 to disable DMA support - chipset doesn't support properly arby73 Linux - Newbie 0 06-13-2001 11:17 AM


All times are GMT -5. The time now is 05:50 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration