bug-ddrescue
[Top][All Lists]
Advanced

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

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


From: Matthew Ruffalo
Subject: Re: [Bug-ddrescue] How about a "don't care" block state?
Date: Thu, 26 May 2011 10:41:45 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10

Ian-

I have no useful advice about a 'minimum image size' parameter beyond what you've already said, but I feel compelled to point out that the --preallocate option does *not* zero-fill the file if you're using a filesystem and kernel that support preallocation. This includes ext4, ocfs2, xfs, etc., but *not* ext3, and I think any kernel past 2.6.22. Your glibc will also need the 'fallocate' system call wrapper, but if your kernel and filesystem are new enough then your glibc almost certainly is too.

If you're not using an ancient system, preallocation is almost instant. For a simple test, try 'fallocate -l 100G file' to see how long it takes to preallocate 100GB:

$ time fallocate -l 100G file

real    0m0.547s
user    0m0.000s
sys     0m0.080s

MMR...

On 05/25/2011 02:03 PM, Ian Abbott wrote:
On 19/05/11 09:47, Ian Abbott wrote:
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.




reply via email to

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