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.
1858
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:
4096
$ sudo blockdev --getbsz /dev/sda
4096
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.
dump
andrestore
- they works on a bit higher level and not dependant on the drive geometry.