[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] How about a "don't care" block state?

From: Ian Abbott
Subject: Re: [Bug-ddrescue] How about a "don't care" block state?
Date: Wed, 25 May 2011 19:03:57 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110510 Lightning/1.0b3pre Thunderbird/3.1.10

On 19/05/11 09:47, Ian Abbott wrote:
> Hi Antonio,
> On 18/05/11 20:11, Antonio Diaz Diaz wrote:
>> Ian Abbott wrote:
>>> My idea is that it should be fairly easy to modify a utility such as
>>> 'partclone' (actually, a suite of utilities for cloning various file
>>> systems) to spit out a ddrescue log file.  If it spat out a '?' for the
>>> used areas of the file system and a 'X' (or whatever will mean "don't
>>> care") for the unused areas, this log file could be used by ddrescue to
>>> recover only the used areas of the file system, ignoring the unused areas.
>> I think this could be better done by using such generated logfile as 
>> argument to the option --domain-logfile. In this case '+' should be used 
>> for the used areas and '?' could be used for the "don't care" areas.
> Yes, that should work just as well.  The --domain-logfile option escaped
> my attention because I've never used it!

I've encountered one minor inconvenience with this technique.  If using
ddrescue with a domain log (generated from a filesystem map) to copy a
partition to an image file that either doesn't exist yet or is smaller
than the partition (actually, smaller than the filesystem on the
partition), then the image file size may end up smaller than the
filesystem.  This occurs if the end of the filesystem is unused (as
determined by the domain log).

For example, say the filesystem size is 0x5D362B000, but the final
0xDE96F000 bytes of the filesystem are unused, the end of the domain log
might look something like this:

0x494C8E000  0x6002E000  +
0x4F4CBC000  0xDE96F000  ?

Now, if ddrescue creates the destination image file from scratch, its
size will end up as 0x4F4CBC000, not 0x5D362B000 (0x4F4CBC000+0xDE96F000).

This may make the image file unmountable using the 'loop' block device,
for example ntfs-3g complains if the block device is too small, even
when mounting read-only.

It's possible to extend the image file afterwards using the 'dd' or
'truncate' commands, and it's possible to create a (possibly sparse)
image file of the correct size before running ddrescue, but it would be
nice if there was a way to set the minimum size of the destination using
ddrescue.  I know it's possible using the --preallocate option but that
(maybe) takes a lot longer as the kernel has to extend the destination
file with zeros to the desired size before ddrescue starts copying the
source to the destination.

If there was an alternative to the --preallocate option that just seeked
the destination to the correct size (perhaps when --preallocate and
--sparse are used in combination?), or an option to seek the destination
to the correct size after the first copying pass, that would be great,
especially if the underlying filesystem supports sparse writes.

To change the subject a bit, the next version of partclone (0.2.24)
should have an option to create a domain log file (with an optional
starting offset).  I've been testing a pre-release version today.  (I'm
not a member of the partclone team, but I submitted a patch to add this
functionality, which was accepted.)

Best regards,

-=( Ian Abbott @ MEV Ltd.    E-mail: <address@hidden>        )=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-

reply via email to

[Prev in Thread] Current Thread [Next in Thread]