Re: [Bug-ddrescue] GNU ddrescue 1.18-pre2 released

[Scott Dwyer]

I just did some testing, and in short, I can confirm that if read speed 
slows down after encountering errors, even when reading another good 
area, that closing and reopening the device does bring the read speed 
back up where it should be. So I am confirming that it is in the kernel, 
and not ddrescue. Although I would like to point out that for me this 
issue does not happen when using the --direct option.

I tested this with a program that I wrote from scratch that can perform 
a simple clone of a hard drive while ignoring bad reads. If anyone would 
like to see the source, I could email it (just understand that it is a 
hack job right now). I don't even want to talk about how long it took me 
to get O_DIRECT to work with a memory buffer alignment:)

So now the big question... What happens every time the input device is 
closed and reopened? I put my ear to the drive when it happened, and did 
not hear anything. But I would not guarantee that it does not send a 
command to the drive to park the head or something. So until we know 
that this is safe, then I think this should be used sparingly. But it 
does work, so now how to implement it...


On 8/17/2013 9:00 PM, Paul L Daniels wrote:
> On Fri, 16 Aug 2013 11:25:55 +0200
> Antonio Diaz Diaz <address@hidden> wrote:
>
> >     * Skip size is now reset (instead of reduced) after good data is
> > found. This should make ddrescue regain speed faster after leaving a
>         I was wondering Antonio, if perhaps a hack way to fix the
>         slow-down problem might be to close, then reopen the source
>         file handle?   If the problem is something within the linux
>         kernel (in my case) then possibly it won't be able to be
>         resolved without reopening the source/file?
>
> Paul.