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
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
