Hello David. Thanks for your interest in ddrescue.
David Burton wrote:
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.
Glad to hear this.
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.
The logfile may become very big and is not created incrementally. So it may be impossible to write it frecuently without intolerably degrading performance. But certainly it can be written periodically.
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?
Sure. The next version of ddrescue will probably feature it.
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.
The logfile works as a TO-DO list. What you are asking for is a NOT-TO-DO list. This is unpractical, because all the list have to be parsed to verify that a sector is not to be read. Also it is unnecesary, because if the logfile is created, no successfully read sector will be tried again.
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 would need a change in the logfile format. I'll think about it, but patches are welcome. ;-)
Also (some day!), it would be nice if it could follow partition table links, and give special emphasis to trying to recover them:
Ddrescue is a general purpose rescue program. Partition tables are a specialized thing. I don't know if this will be implemented someday.
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?
Sure.
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.
I think this also can be done. Or at least add a '--force' option.
Regards, Antonio Diaz.
_______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
