Hello Sharukh!
First of all this is nothing ddrescue itself supports programmatically. It is
completely agnostic to partition tables, metadata, filesystems etc., operating
strictly on (mostly raw) block devices.
So taking care of all that is not a question of bugs or features, but of the
adequate usage of ddrescue. However, since this „bug“ mailing list
traditionally also serves as a user support group to some extent, I’ll give you
my ideas for your workflow.
How about working on the partition level instead of whole drive? That means you
would have to prepare your destination drive beforehand to be a GPT drive with
suitable placeholder partitions (of the correct size, type and label) to
receive the partition(s) you’d like to clone. Then you proceed like you did
before, just with partition device identifiers, so e.g.
ddrescue -f /dev/sda3 /dev/sdb2 mapfile
If that method will also work (like in your example B, using -s) to clone to a
smaller partition, is entirely dependent on the filesystem that resides in the
partition.
Greetings, Florian
Am 13.04.2025 um 07:49 schrieb Shahrukh Merchant
<shahr...@shahrukhmerchant.com>:
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
