Hello Antonio, I start from the end of your letter.
> I guess you mean "marking differently blocks skipped after finding a > slow area from those skipped after finding an unreadable area". This > could be useful, but is a major change to the current algorithm. I'll > think about it. Feedback is welcome. :-) Yes, this is what I mean. Is it really a major change? Marking these areas differently seems to me an easy change. If ddrescue would take as non-tried not only the areas with '?', but also areas with the new 'slow' mark, it would result exactly in the desired functionality. What am I missing? > Not exactly. Slow areas are indeed read correctly, so they are marked > as '+' (finished). If the read rate of such a correctly read area > falls below the --min-read-rate, ddrescue will then skip ahead a > variable amount depending on rate and error history. This skipped area > will be marked as '*' (non-trimmed). I also thought it works like this, maybe I was not so clear. The key is to treat these areas independently, and allow a second (or more) run with -n for these. > The areas marked as non-trimmed are tried before splitting. So they > are tried in a run with the -n option. The problem is you can run > ddrescue only once with the "-n" or "--min-read-rate" options. The > second time you use the "-n" option, ddrescue does nothing because > only non-split and bad-block areas are left. The second time you use > the "--min-read-rate" option, it has no effect because no more > non-tried areas are left. Basically I would like to run ddrescue more than once with the -n option, to try again slow areas, but leave out bad areas. In my case I have choosen to run ddrescue first with a higher speed threshold, then change all '*' area to '?', and read again with a lower speed threshold. This way I was able to first recover the fast areas, then the slower ones. The price was to try bad areas twice. As I have several bad areas with different sizes, this increased second run significantly, but at least I was sure, the a big part is saved in a few hours during the first run. Regards, Gábor _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
