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

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.

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

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).

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.

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.