Re: [Bug-ddrescue] Sparse and preallocate questions/feature idea

[Zeniff Martineau]

Hi~

Antonio Diaz Diaz wrote:
> No, because estimating sparseness is not trivial for files and not possible
> for drives.
>
> A dry-run on a failing drive just to estimate the amount of sparseness? Does
> not sound good.
>
> AFAIK, reading the whole drive is the only way to know the amount of
> sparseness of the resulting file.


Thank you~:) That answers my main questions.

I agree it's not good. I accidentally overlooked the main purpose of
ddrescue was for failing drives. At the time, I was using it for old
drives I didn't use for a long time and found again, so I didn't
expect them to be bad and forgot about that point.


General followup sparse/usage check question (not specific to ddrescue):
I was thinking if estimating could be possible by testing a few chunks
at a time progressively toward the end of the drive, skipping large
amounts, to see when/where the drive seems to have stopped "filling
up". On a healthy drive, would this make sense for a very rough usage
guess? Or maybe the drive just puts data anywhere without regard to
physical location, so that wouldn't work? Just curious, since I think
I remember running photorec on a very large drive with almost no
usage, and it seemed to finish pretty fast, so I was assuming it was
able to check something like that. But I will ask them too; I just
wondered about that for ddrescue too. :)


Main followup question:
If ddrescue runs out of room on the destination output file's HDD, is
there a way to resume where it left off in another output file on a
different HDD? Would using --input/output-position be enough? I think
the split(1) utility can split files and put them back together with
cat(1), but I have no idea if using cat like that would work or be
efficient for large ddrescue output files?

I can see this happening for new users who feel they need as much
copied as soon as possible for something suddenly failing, but who
might not have a drive with enough room at that time. They might be
able to get all of the output in total but split because of that on
different HDDs, and later put it back together when they have time to
get a new HDD with enough room.