I would like to move a partition to a new drive. The old drive has a sector size of 512 bytes while the new one has a sector size of 4096 bytes. I tried doing a dd of the full disk, but that failed because the partition on the old drive was not aligned to 4K boundaries. So instead I created a partition from scratch on the new drive using fdisk, then copied that partition between disks using dd. Finally, I expanded the filesystem on the new drive using resize2fs. This appears to have worked, as I can mount the new partition (read-only so far) and view files, and fsck says it is clean.

But I still have lingering doubts about whether this is a safe thing to do. For example, does the FS care about the sector size in a way that would break things by doing this, or is it shielded from that by the VFS layer or HD itself?

  • 1
    Use dump and restore - they works on a bit higher level and not dependant on the drive geometry. – Kondybas Dec 22 '13 at 7:33
  • 1
    How dd did fail when you tried to copy full disk? – sendmoreinfo Dec 22 '13 at 8:07
  • Sorry, I worded that poorly. dd itself didn't fail, it's just that I couldn't use the partition that was copied. fdisk -l warned that the partition was not aligned to sector boundaries, and no device appeared for the copied partition (eg there was just a /dev/sdd and no /dev/sdd1). – pavon Dec 23 '13 at 0:35

You haven't told us what was the dd command that you tried initially which failed. However, I spent a bit of time checking the source code of dd command (from coreutils package) and looks like we had a problem here.

1852   /* Some devices require alignment on a sector or page boundary
1853      (e.g. character disk devices).  Align the input buffer to a
1854      page boundary to cover all bases.  Note that due to the swab
1855      algorithm, we must have at least one byte in the page before
1856      the input buffer;  thus we allocate 2 pages of slop in the
1857      real buffer.  8k above the blocksize shouldn't bother anyone.
1859      The page alignment is necessary on any Linux kernel that supports
1860      either the SGI raw I/O patch or Steven Tweedies raw I/O patch.
1861      It is necessary when accessing raw (i.e. character special) disk
1862      devices on Unixware or other SVR4-derived system.  */

If you give the error message, I can do a further search. But to me, this is where we got hit. That is aligning 512 byte page boundary with a 4 KiB page boundary doesn't seem right.

Now, coming to the second part, did you create the partition of the second drive (with fdisk) as 512 byte size. However, the sector size advertised by most modern disks to OS is 1 MiB that is 4096 KiB.

In the function update_sector_offset of fdisk.c you will see

             * Align the begin of partitions to:
             * a) topology
             *  a2) alignment offset
             *  a1) or physical sector (minimal_io_size, aka "grain")
             * b) or default to 1MiB (2048 sectrors, Windows Vista default)
             * c) or for very small devices use 1 phy.sector
            sector_t x = 0;

            if (fdisk_dev_has_topology(cxt)) {
                    if (cxt->alignment_offset)
                            x = cxt->alignment_offset;
                    else if (cxt->io_size > 2048 * 512)
                            x = cxt->io_size;
            /* default to 1MiB */
            if (!x)
                    x = 2048 * 512;

            sector_offset = x / cxt->sector_size;

*cxt is the descriptor to the fdisk struct.

So, this part is not clear to me. That is, if your new disk advertised the sector size as 4096 KiB or 512 bytes.

Now, coming to the last part.

No, filesystems don't actually care about sector size. And as long as the block size is 4 KiB, things should be fine, because, since virtual page size (in mm context) is 4 KiB, the mmaped IO needs to be aligned with that. In my laptop, the block size and physical sector size is the same.

$ sudo blockdev --getpbsz /dev/sda
[sudo] password for chakraborty: 

$ sudo blockdev --getbsz /dev/sda

IO happens in context of block size, not sector size. If due to physical sector size FS encounters any problem, I would be very surprised. However, VFS doesn't come that far. VFS is between application issuing IO and the actual filesystem. What we are discussing is below VFS layer.

  • On my new drive the block size and physical block size are both 4096, while the old drive has a block size of 4096 and a physical block size of 512 (as given by blockdev). So what you are saying is that the filesystem only cares about the block size and not the physical block size, which hasn't changed, and therefore I shouldn't have any problems. Makes sense. Thanks! – pavon Dec 23 '13 at 19:09
  • Yeah, if the physical sector size of the old drive is 512 bytes then, it explains the problem clearly. You cannot align 512 byte disk with 4096 KiB disk boundary. And your new disk shouldn't have any problem, that is all. BTW, if the answer helped you, feel free to mark it off as the correct answer :) – Soham Chakraborty Dec 24 '13 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.