Hi: I'm using this program to recover a quite damaged disk, but I'm having to keep stopping it and inserting alternative start point manually when it finds a hard zone due to the particular damage pattern this disk has, which ddrescue doesn't seem to handle very intelligently.
ddrescue's skipping strategy seems to be geared towards very localized damage while my disk has a good deal of damage spread in what seems to be a ratehr constant pattern through all of the disk. apart from unrecoverable damage it also has "hard parts" on which ddrescue (and all other recovery programs I tried before) spends a lot of time for very little data. The first time I ran ddrescue, when it hit the first error, it started skipping blocks in geometrical progression. it was noticeable when it jumped 1gib, then 2, then 4, 8, 16, 32, 64, 128 gb... it's a 160gb disk so it ended the first pass quite fast, but then it slowed to a crawl on hard zones during the trimming pass. The thing is the disk has good dat all over, but ddrescue just hit bad zones after every jump, assuming all in between was bad to, and then stalling with hard to read parts. I had to go manual. In most of this disk there seems to be a rather constant pattern of 50-70mib of "hard zone" and then 150-200 (or enven more at times) of easily readable data, so what I did was stop the program after it hit a problematic zone (reducing cluster size to 1 to reduce the response time, because it was crazy with the default 64kb clusters), and start it again with a start point that was 50-70 mib higher than the last good read. this afforded me a long wait (and possible unreasonable skipping and worthless and dangerous attempts at reading bad areas before good ones) and once the disk started responding again, it ran through the next 150 or so megabytes at normal speeds, and then repeat, and repeat, etc. Eventually when I finish this I'll let it run normally on what's left (untrimed/unsplit areas), but for now the default skipping strategy just doesn't work for me. So, my suggestion is as follows. Make a new mode so the user can specify custom skipping patterns: In my case it would be like: unpon hitting a problematic zone (read error or just a "slow/hard zone") that makes recuing stall, jump 50mb, if still no good data found, jump an aditional 10, then 20, then another 10 or 20. if, after a number of errors you haven't found good data, make a bigger jump, like 200mib or 500 then start with 10-20-50 again. and optionally the geometric progression could be implemented too as last resort. possible commandline argument could be --skipping-pattern=50Mi,10Mi,20Mi,10Mi,20Mi,200Mi,50Mi,g10Mi what this would do is try intial jump of 50Mib. if no good area is found, try 10Mib more, then 20, then 10, then 200, then 50Mi again then geometric progression augments of 10, 20, 40, 80, 160, etc megabytes (g of geometric) or something like that... xD the pattern description format can surely be made more inteligent and flexible, but seeing how my disk is, it would probably work for me. additionally, before the trimming step (which, as I understand it, consist of reading clusters from the tail), add an additional similar step could be added just after the initial read. it would consist of reading clusters (or a specially specified ammount of data, like 1mib, for example) from the start of the jump landing points. That is, say the intial forward read made a jump from the 150Mib position to the 220 position, but maybe there are still some "easy" data at 219mib position or before. instead of trimming clusters, trim zones, starting at the initial points (landing zones) of successful reads after a jump. so if the first read through landed at 220, then try reading 219, then 218, then 217, etc until a bad zone is found. now to define what is a bad zone (or specifically what is a SLOW zone) a few metrics could be defined, like "average read speed in the last 10 seconds" or something else that denotes that time is being spent on a bad zone while you could be trying somewhere else for bigger profit and leave the slow zone for later xD _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
