bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ddrescue] On the reading of slow areas (option introduced in 1.


From: Antonio Diaz Diaz
Subject: Re: [Bug-ddrescue] On the reading of slow areas (option introduced in 1.15pre2)
Date: Mon, 10 Oct 2011 17:16:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

Hello Gábor,

Gábor KATONA wrote:
If I noticed it correctly, than all areas which fall below the given threshold gets marked with *, meaning failed block non-trimmed.

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).


If I understand the algorithm correctly, these blocks will not be read on a subsequent run with a -n option, but only when we turn to splitting.

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.


If this is correct, I would suggest to have a new logfile status character meaning "slow block", and have a new option meaning "try again slow blocks". This way slow blocks would not be marked as bad blocks, and they could be saved before turning to the most difficult parts, but only after the most healthy blocks are saved.

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. :-)


Best regards,
Antonio.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]