512B to 4KiB (Advanced Format) HDD cloning with dd

Question

What is the best practice to clone with a dd an existing 512-bytes-per-sector HDD (whole disk, not specific partitions) to a modern 4-kibibytes-per-sector Advanced Format drive? What options should be used? Does they matter at all?

Answer 1

Okay, I think it is worth to post what I have done myself as an answer.

I've used the following command to clone the drive:

dd if=/dev/sda of=/dev/sdb ibs=512 obs=4096

Here, the first option ibs instructs dd, that 512 bytes should be read from the source at a time and obs that 4096 bytes should be written at a time to the destination.

The whole procedure went without any issues. After it was completed, I disconnected the former drive and did try to boot from the new one. It booted and all of partitions were properly shown.

To be assured if the aligning is good for this Advanced Format drive, I've downloaded WD Align tool from the Western Digital website and it shows, that all is properly aligned, here is a screenshot:

I don't know if extra options was of any use for this though.

Answer 2

Which kind of advanced format drive is it? Does it have the "AF" logo (which means the drive presents 512-byte sectors at its interface, i.e. it's really a "512e" drive) or the "4Kn" logo?

If the former, you don't have to do anything special - you can treat it just like a legacy drive, though proper partition alignment is a good idea (it can make a huge difference in performance).

If the latter, you can't copy it "without any modifications", because the file system metadata has to change. For example, a 512e "4 GB" drive will have LBNs from 0 through about 7,812,500,000, while a true 4K native "4 GB drive"'s LBNs will only go up to about 976,562,500. So the LBNs in the metadata of a 512-byte-per-sector drive would make no sense on the 4Kn drive.

Answer 3

Because you're using a 512e drive, your dd example is unecessary. You could have simply used dd if=/dev/sda of=/dev/sdb bs=2M (what I tend to use). The real issue is going from 512n to 4Kn, and basically, it's not cut and dry. In most cases, it's probably best you repartition and cp -a everything back in addition to reconfiguring your boot loader, etc.

Whether or not you can dd back and forth between 512n and 4Kn with minimal, non-destructive repartitioning, depends on whether or not you used/use 512 multiples of 8 (512 * 8 = 4096) for your partitioning.

Example:

512n partition under gdisk:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  linux-bios
   2            4096        41943006   20.0 GiB    8E00  linux-lvm

4Kn translation after dd'ing (from 512 to 4096 physical and logical),
then re-repartitioning:

Number  Start (sector)    End (sector)  Size       Code  Name
   1             256             511   1024.0 KiB  EF02  linux-bios
   2             512        5242875.75 20.0 GiB    8E00  linux-lvm

Whoops! Notice the decimal point, (41943006+1 / 8)? That ain't going to work.

The only way is if you have more than 20.0 GiB on the new drive and add an extra 4kn sector (5242875+1), then resize the underlying file system, lvm, etc.

Now if you had partitioned your 512n drive using multiples of 8, then the first (512n) partition table above would have looked like this:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  linux-bios
   2            4096        41942999   20.0 GiB    8E00  linux-lvm

And the proper 4Kn translation would look like this:

Number  Start (sector)    End (sector)  Size       Code  Name
   1             256             511   1024.0 KiB  EF02  linux-bios
   2             512         5242875   20.0 GiB    8E00  linux-lvm

(41942999+1) / 8 = 5242875

Moral of the story: if you plan on using 4Kn drives in the future, partition your 512n drives using multiples of 8 and you should be fine as long as you recreate the partition table accordingly.

Note: don't forget about any possible GUID cloning, not just for the Disk identifier, but the partition GUIDs too.