I've been using ddrescue to clone MBR hard drives for many many years,
even when the source and destination drives are of different sizes. This
has been rather trivial in the case of MBR drives:
A. If destination drive capacity > source drive capacity
ddrescue -f /dev/sda /dev/sdb mapfile
i.e., nothing special to be done and any extra space on the destination
drive is just unallocated and can be used to expand the last partition
or create a new one with standard disk management tools on Windows or Linux.
B. If destination drive capacity < source drive capacity (of course the
allocated partitions still must fit within the destination drive, with
unallocated sectors at the end, which occurs quite frequently in my use
cases)
ddrescue -f -s12345678s /dev/sda /dev/sdb mapfile
where one would use "fdisk -l" to determine the last-used sector of the
last partition to use with the -s option (after adding 1)
The problem I now have is with GPT drives (I resisted crossing the 2 TiB
threshold till now ...) which have several sectors of backup partition
table and other information at the very END of the disk as well as the
beginning (regardless of unallocated space in between). So my approach
above needs to be augmented to take into account this additional
structural information stored not only at the very start of the disk as
in the case of MBR drives, but also at the very end. How would I need to
adjust my ddrescue commands to take this into account? Specifically:
1. What command can I use to get the sector number and size of the
position of the secondary GPT header at the end of the disk?
2. Is there any other structure information scattered elsewhere on the
drive (i.e., other than at the very beginning and the very end) that
would complicate this even more?
3. How would I modify my simple 1-liner ddrescue flow (to presumably
multiple invocations) to copy all the relevant parts and have a clean
GPT drive at the end of my cloning operation in the case where the disks
are not EXACTLY the same size?
4. Another more subtle problem: There is also a protective MBR on a GPT
drive that makes the entire drive look like a single partition fully
allocated disk, and this would also need adjustment of the faked
partition size if the destination drive is larger or smaller than the
source drive; so where and how would that adjustment need to be made?
More fundamentally, I'm actually surprised that this hasn't come up
before since GPT drives have been around for a while now and I would
imagine that rescuing or cloning to a drive that is larger than the
original would be a frequent occurrence. For the purely cloning
application perhaps there are other tools that take care of this, but
they typically aren't doing any rescuing. And even though the end result
would be useable since the primary GPT header and partition information
would still be intact, the secondary header/partition info blocks would
indeed be corrupted.
I believe gdisk will fix this corruption both by recreating the
secondary end-of-disk partition information and fixing the protective
MBR info, but this is not self-evident and it seems anecdotally that
many tools including gparted will choke on the mismatch and not
recognize any partitions, which would cause unnecessary anguish when in
fact the disk might indeed be entirely useable.
Perhaps a new option for ddrescue is called for here? A
"GPT-fix-unequal-source-vs-destination-size" option? Which of course
would only apply in the case of a complete disk copy (i.e., not a
partition copy, which wouldn't have this problem).
Shahrukh Merchant
