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