Ubuntu – dd, device clone to smaller drive, no space left on device

Ubuntu

I've seen numerous questions, answers, and guides relating to use of dd, cat, and clonezilla to facilitate partition and device cloning. Rather than continue those discussions I'm hoping to give very targeted questions to dd behavior within this post.

I'm using Ubuntu 18.04 LTS live, booted from USB. I have a 500gb HDD with Windows7 (/dev/sda). I've resized the partitions such that slightly more than 420gb is unallocated. I aim to backup the boot table and partitions to a 120gb SSD (/dev/sdb). The SSD has no partitions and shows 110gb unallocated.

sudo dd if=/dev/sda of=/dev/sdb hits failure and conveys 'No space left on device'. Spot checking partitions using gparted, I see /dev/sdb contains the same partitions, labels, size, and unused. The only noticeable difference is unallocated space.

I am able to boot Windows from the SSD but am left with a few questions related to dd behavior.

  • did dd attempt to copy device content which was not allocated?
  • does dd have an order of operations? (something like partition 1->99, then misc drive blocks)
  • by chance have I just been lucky so far in my immediate use of this Windows drive? am I being overly paranoid in thinking the drive is missing content?

For what it's worth, I do plan to retain the HDD for the foreseeable future.

Best Answer

dd does not know anything about partitions or any other structure on the disk. It doesn't recognize "allocated" or "unallocated" parts of the disk. From dd's point of view, a device given as parameter consists of a series of blocks. Thus, if you run dd if=/dev/sda of=/dev/sdb, dd will copy blocks starting from the beginning of /dev/sda to the correspondingly numbered blocks on /dev/sdb, until it has read all blocks from /dev/sda or until it hits an error. In your example, because /dev/sdb was smaller in size than /dev/sda, dd was terminated with the error message "No space left on device" (on /dev/sdb).

Related Question