On 9/9/20 2:21 PM, Carlos E. R. wrote:
El 2020-09-09 a las 16:59 +0200, Bengt Gördén escribió:
-a bytes --min-read-rate=bytes Minimum read rate of good non-tried areas, in bytes per second. If the read rate falls below this value during the first two passes of the copying phase, ddrescue will skip ahead a variable amount depending on rate and error histories. The skipped blocks are tried in additional passes (before trimming). If bytes is 0 (auto), the minimum read rate is recalculated every second as (average_rate / 10).
-O --reopen-on-error Close infile and then reopen it after every read error encountered during the copying phase. If '--min-read-rate' is set, also close and reopen infile after every slow read encountered during the first two passes of the copying phase. Use this option if you notice a permanent drop in transfer rate after finding read errors or slow areas. But be warned that most probably the slowing-down is intentionally caused by the kernel in an attempt to increase the probability of reading data from the device.
I don't think it was slow read, but that ddrescue can not do read and write simultaneously, as dd does.
i/o graph, more or less:
sdc (read):
******** ******* * * * * * * * * ***** ********* *******
sdd (write):
***** ******** ******* * * * * * * * * * * ******** ******** *******
The algorithm is designed to be somewhat slow, much slower than dd according to https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Algorithm and unless the -O or --reopen-on-error isn't modified, then the kernel may intentionally further slow the reads even more to attempt a more full recovery. I can see this becoming more of an issue on multi-terrbyte drives. We are victims of our own success (excess). -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org