[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.
Antonio Diaz Diaz
Re: [Bug-ddrescue] On the reading of slow areas (option introduced in 1.15pre2)
Mon, 10 Oct 2011 17:16:05 +0200
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905
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. :-)