On Thu, 07 Jun 2012, Michael van Elst wrote:
So if I use dd(1) or equivalent to copy the data from a disk with 512-byte sectors to a disk with 4096-byte sectors, and if the data includes a WAPBL wile system, then it won't work?Sort of.The WAPBL code will probably think that the journal is invalid or it could interpret some arbitrary data as journal. Not good. You should drop the journal with tunefs before mounting with a different blocksize.
Sure, I can do that, but I think that offsets and pointers and such in on-disk file system formats should be in device-independent units wherever possible. That probably means in bytes or in units of 512 bytes.
The fileystem tools like fsck _will not work_ independent of whether you use WAPBL or not. That's because the superblock still stores information in terms of the physical disk for compatibility and userland tools like fsck still use the superblock information.
OK.
To make fsck work you need to patch the superblock to reflect reality, but I fear there is no tool for that. Maybe we should invent a tunefs option to adjust the superblock.
Yes, we probably do need a superblock conversion tool. It would be nice if, in future, the superblock could use device-independent units.
Can we fix this? Can we fix it before next week, when I plan to upgrade my laptop's disk to one with 4kB sectors?I rather doubt that this is an issue for you. Very few disks expose the 4kB sector size these days (short of USB disk enclosures).
I'll see when I get the disk.
You can use 512 byte transfers and the only issue is performance when you don't align the partitions to the physical block size, which is something that won't happen by just copying the disk image.
Yes, alignment can be an issue, but I prepared for that years ago by aligning disk partitions to probably-larger-than-necessary powers of 2, like 16kB or even 1MB.
--apb (Alan Barrett)