It sounds like you have figured out the "tricky" part. I had thought
about suggesting doing the "re-open" before skipping ahead due to slow
speed, and if the speed didn't go up then skip ahead. But it sounds like
you have a much better combination of ideas than I was coming up with. I
do agree that once past the "fast" copy stage, there is not really a
need to try to increase the speed, especially if going slower helps the
read chances.
As for the skip rate, that still sounds a bit tricky.
On 8/27/2013 7:41 PM, Antonio Diaz Diaz wrote:
The kernel code linked by Sam gave me some ideas. It seems the kernel
counts the number of different classes of errors occurred in the last
5 or 10 minutes. So it may be a good idea to fly away from errors
_and_ slow areas.
I have just uploaded version 1.18-pre4[1] with the effect of
'--reopen-on-error' limited to the copying phase, but reopening the
input file also on slow reads (i.e., every time ddrescue skips ahead).
A slow speed while reading sector by sector (while trimming, splitting
and retrying) may help to read more sectors, as the kernel developers
intend.
I have also changed the default value of '--min-read-rate' to 0
(auto), so that slow areas are skipped by default. Maybe the default
value (average_rate / 10) is too low and will need furter adjustment.
[1]http://download-mirror.savannah.gnu.org/releases/ddrescue/ddrescue-1.18-pre4.tar.lz
Hope this helps,
Antonio.
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
