[Bug-ddrescue] On the reading of slow areas (option introduced in 1.15pre2)

[Gábor KATONA]

  Dear Antonio,

Unfortunately I had to try your excellent program. I still need lot of 
work to finish, but it really seems to work, thank you very much.

My drive is damaged in a way, that is has several very slow areas 
surrounded by less slow areas, surrounded by even less slow areas 
embedded in the normal area, so I'm using 1.15pre2 with the 
--min_read_rate option.

If I noticed it correctly, than all areas which fall below the given 
threshold gets marked with *, meaning failed block 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. My 
experience also suggests this behaviour. The problem with this strategy 
is the following. If I first want to rescue the most healthy parts, I 
would run

ddrescue -n --min-read-rate=5M device image log

When it finishes I want to give a chance to slower parts, but not to 
very slow ones, so I would issue

ddrescue -n --min-read-rate=100k device image log

As I understood and experienced this will not work as I expect, because 
blocks that were skipped during the first run are not read in this run.

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. In cases similar to mine 
it would increase the number of saved blocks by several percents (I 
guess in my case about 10%) during the first, let's say, day. Saving all 
slow blocks can require several weeks, and the drive could totally die 
during this.

Thank you again for ddrescue,

Gábor Katona