dd to clone to smaller sdcard

Question

One of my Raspberry Pi's is using a 4GB SDcard for the root/boot filesystem.

As seen when mounted on another system:

Disk /dev/sdc: 3904 MB, 3904897024 bytes
121 heads, 62 sectors/track, 1016 cylinders
Units = cylinders of 7502 * 512 = 3841024 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000714e9

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               2          17       57344    c  W95 FAT32 (LBA)
/dev/sdc2              17         800     2938880   83  Linux

This shows that I'm only (and deliberately) using 3GB of the available 4GB and that the cyclinders in use are aligned to the beginning (if flash memory even works that way).

In the past I have used the cp command to migrate an existing filesystem to a smaller (already formatted) target filesystem but I prefer the simplicity of the dd command.

Q1: Can I safely use dd to clone this disk to another, slightly smaller (44MB smaller to be precise) 4GB SDcard?

If the source disk had a second partition that filled up the entire remaining disk space but had a filesystem that was only partially used, I'm pretty confident that over time I could end up with scattered bits of files even near the end of the partition (potentially overwriting the boundaries of the physical target disk).

Q2a: is there perhaps a move-files-to-beginning-kinda-defrag command that I can run to make sure the end of the partition was unused?

Q2b: if I knew the end of the partition was unused, could I safely truncate the partition with dd to the smaller target disk and correct the misalignment afterwards with a simple fsck?

Solution 1

If you're absolutely sure that the end of the last partition fits on the target drive, you can copy the drive wholesale. Don't use dd, which is slower (unless used with additional options, and not always even then) and more error-prone; simply use cat.

cat /dev/sdc >/dev/sdz

Replace /dev/sdz by the proper path to the drive that you want to overwrite. Make sure you get it right, since a single-letter typo could wipe out your system! You can usually access disks through entries /dev/disk/by-id/ or /dev/disk/by-path/, whose name contain an indication of the disk model and how the drive is connected — this reduces the risk of errors considerably.

It would be less error-prone to create a partition table on the new disk (with fdisk or other tool of your choice), making sure that the target partitions have the same size (or larger) than the source partitions, and then copy each partition, e.g. (if you keep the same partition numbers)

cat /dev/sdc1 >/dev/sdz1
cat /dev/sdc2 >/dev/sdz2

Just because a partition (more precisely, a filesystem — What mount points exist on a typical Linux system? provides a bit of background) isn't full doesn't mean you can copy the beginning of it and leave out the end. You can't predict where files will end up, and filesystems contain control data; copying a truncated filesystem will give you a broken filesystem (and don't count on fsck to fix that — it'll might you something usable, but it can't restore the files whose content was outside the copied part).

If you want to copy or move a partition to a smaller space, or simply to shrink a partition, first shrink the filesystem that it contains. For example, for an ext2/ext3/ext4 filesystem, run resize2fs to shrink the filesystem. Shrinking the filesystem is the “move-files-to-beginning-kinda-defrag” operation that you wanted. Then you can use a tool like fdisk to shrink the partition, or copy the filesystem to a smaller partition. Just make sure that the size of the partition is larger than the filesystem. GNU parted can sometimes shrink a filesystem and the containing partition in one go (it depends on the filesystem and partition type).

Solution 2

You can use dd to create copies of the partitions and not of all the device.

dd if=/dev/sad1 of=/tmp/boot.img
dd if=/dev/sad2 of=/tmp/root.img

As for Q2b:

I did this several times, never had a problem, but still this is not recommended.

Comments

[captcha]

Many thanks for suggesting the cat method, I will appreciate any gain in speed in the cloning process.. In your second paragraph you mention to use fdisk and then cat. Isn't cat going to overwrite any existing partition tables that were just created by fdisk?

[captcha]

Thanks for the feedback although I prefer to have the disk clone process to be just a single command. Great to hear you had some success with the Q2b method, that makes me a little more hopeful. These disks are very infrequently written to as I have been

[captcha]

...bitten by too many disk writes to SDcards. My aim is to have a zero-disk-writes system and hope to therefore minimise the risk of having valueable data at then end of the filesystem.

[Gilles 'SO- stop being evil']

@captcha No: use cat on the partition (I've added a code example).

[captcha]

Ah, that makes more sense, thanks. I'll do a bit of experimenting to get the feel of how cat should behave as opposed to dd. One reason I prefer the device (sdc) method, rather than the partition (sdc1) method is to preserve the boot sector.

[Rabin]

@captcha, you can also use a utility which aware the fs, like partclone.