[Bug-ddrescue] ddrescue starts over from scratch unnecessarily because no logfile after success & no logfile after crash

[David Burton]

I did a quick benchmark, and Diaz ddrescue copies data from
non-failing drives nearly twice as fast as Garloff dd_rescue.
That's the good news, and it is VERY good news, because dying
drives commonly ROT, which means that the longer a rescue
takes the worse the chances of success.

The bad news is that I have to go back to dd_rescue+dd_rhelp,
because ddrescue can't be rerun to resume the rescue.

The problem is that in two common situations ddrescue doesn't
create its logfile, so when it is rerun it has to start over
from scratch because it doesn't know what it has already
copied to the new drive.

It is apparently designed to create its logfile when it exits,
so when there's a crash there's NO logfile created.  I'm trying
to rescue data from a flakey drive that often crashes the PC,
so crashes happen a lot.

Also, if it copies the data without any error, it doesn't
create a logfile at all, so the next time you run the same
ddrescue command it has to start over from scratch.  Ouch!

The bottom line is that if you make a script of ddrescue
commands to try to rescue various areas of a hard disk drive,
you can't just run the script repeatedly to rescue the data.
If you try that, it'll spend most of its time uselessly
recopying the same data that it had successfully already
copied (and all the while the drive rot is worsening).

Could you possibly add a feature to make ddrescue update the
logfile frequently (and flush/write-through both output and
logfile each time!).  Every 5 seconds would be fine.

Also, could you add an option to make it ALWAYS create its
logfile, so that the same command can be run twice without the
second attempt having to recopy all the data?

If you would make these two changes, then the logfile would be
aproximately up to date even after a crash, and ddrescue could
be rerun without much recopying.

Also, I'd like to suggest some more general enhancements.

It appears that ddrescue only records errors in its logfile,
and not successes.  So I don't think that can ever work right
for a drive-to-drive copy (as opposed to a drive-to-file copy),
since it'll never know what NOT to try to copy again.  I really
wish it were enhanced to record its successes and not retry
them the next time it is run, even when doing a drive-to-drive
copy.

Also, it would be VERY useful if the same logfile could be used
for multiple commands that copy different areas of the drive,
and for multiple recovery attempts over different subsets.
This is an example of what I'd like to be able to do:

#!/bin/sh
# first, rescue the most important parts
ddrescue -i0 -o0 -s50Mi /dev/hdg /dev/hde ./ddrlogfile
# the very beginning is very important (should NOT retry what it has already 
done)
ddrescue -i0 -o0 -r3 -s1Mi /dev/hdg /dev/hde ./ddrlogfile
# try to rescue some key disk areas first
ddrescue -i30Gi -o30Gi -s10Gi /dev/hdg /dev/hde ./ddrlogfile
ddrescue -i40Gi -o40Gi -s10Gi /dev/hdg /dev/hde ./ddrlogfile
ddrescue -i230Gi -o230Gi -s5Gi /dev/hdg /dev/hde ./ddrlogfile
# then try for the rest (should NOT retry what it has already done)
ddrescue -i0 -o0 /dev/hdg /dev/hde ./ddrlogfile
# and try again for stubborn errors
ddrescue -i0 -o0 -r3 /dev/hdg /dev/hde ./ddrlogfile

Also (some day!), it would be nice if it could follow partition
table links, and give special emphasis to trying to recover
them:

ddrescue -i=parttable /dev/hdg /dev/hde ./ddrlogfile
(Subsequent ddrescopy copies using the same ddrlogfile would,
of course, avoid recopying those same sectors.)

Also (this is minor), when it complains that the command has
failed because with the specified parameters it would copy from
beyond the end of the drive, could ddrescue please show what
maximum numbers WOULD work?

Also (this is minor, too), it would be nice if there were two
variants of the -s size option.  One varient would generate an
error if it is too big (tell what the maximum -s option value
can be).  The other variant would be a maximum/limit, so that
if the value is too big it will still work, and just generate
a warning.


Thanks!

-Dave
dave304 at burtonsys.com