Re: Re[2]: ddrescue -- basic question -- not a bug--

[Robert Backhaus]

Normally, if  ddrescue run takes longer than it should, then the cause
is that the drive was faulty, and was doing multiple retries before it
returned the data. In this case, ddrescue is doing what you want it to
- the drive is slow, ddrescue is working normally.

There are ways to make the first parts of the read faster, but they
result in read errors and are done so you can get as much data off the
drive as possible before it dies completely. These include using the
--min-read-rate= option, so ddrescue will treat sections that read
slowly as errors so it will skip them in favor of other parts that
might read faster, altering the operating system's drive timeouts so
the OS will give up on reads faster, and setting options in the drive
that reduce the number of retries (normally only an option on drives
with data-center specific firmware). But these options won't speed up
the whole drive read - they'll just run faster at the beginning, then
slow way down at the end.


On Mon, 6 May 2024 at 23:50, Tom Luoma <luoma@midrivers.com> wrote:
>
> Hi Rog and Antonio,
> Thank you both for your quick responses. Maybe I'm just being dim -- maybe I 
> should have given more info.
> I have been using ddrescue since 2016 to clone these drives back and forth 
> about 12 times.  So each drive has about 4 years of 24/7 runtime in a DVR. 
> (WD Purple HDs in eSATA boxes.)
>
> The comand line I was told to use is ---  ddrescue  -f  -n  /dev/sda  
> /dev/sdb  tivo-rescue.log
> Typical results reported over 11 clones -- Run Time (7:58:58), Avg Xfer Rate 
> (69.608MB/s), Errors (0)
> Never any errors reported.  Same desktop but due to installed disks the 
> command line drive letters change
>
> Then, run 12 reported 4:42:33, 117MB/s, 0     And the clone to my surprise 
> ran fine & no lost data.
>
> I never do repairs on DVR drives and simply buy new ones when the DVR acts 
> up. I just bought replacements for these two.  I just need to clone them.
>
> So is there anything I might have done to the command line (or could do in 
> the future) to make the run faster as it did the last time?
>
> Best regards,
> Tom
>
>
> ----- Original Message -----
> From: Antonio Diaz Diaz <antonio@gnu.org>
> To: Tom Luoma <luoma@midrivers.com>
> Cc: <bug-ddrescue@gnu.org>
> Sent: 5/4/2024 8:37:42 AM
> Subject: Re: Fw: ddrescue -- basic question -- not a bug--
> ________________________________________________________________________________
>
> Hi Tom,
>
> Tom Luoma wrote:
> > Is it possible the last time I forgot the log file parameter and that is 
> > why it ran so much faster?
>
> It is possible, but only if you wrote the mapfile (log file) to a extremely
> slow device (about 30 Bytes/s) or to a place that somehow interferred with
> the copy.
>
> Best regards,
> Antonio.
>