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 _______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
