Do you have the "reopen" patch that I can try on my 18pre2 copy
here so that I can see how the performance changes?
No, I do not have a patch for ddrescue. I wrote an independent program
for myself to test and prove the theory. Antonio will have to make any
changes to ddrescue as he wishes.
For what ever reason, it still slows down for me with
--direct, I've also noticed that using --direct causes
different "severe failure" behaviour when reading from USB
bridges, sometimes requiring a reboot to resolve.
The fact that you are using a USB bridge can answer why the --direct
does not work. I have a USB adaptor, and it seems to work ok with IDE
devices. But it will not show the errors with a SATA drive. It will slow
down where the errors are, but will not report them as an error (so a
bad drive will actually not seem to have any errors, but will just be
really slow). It will instead return what I would call garbage data back
in place of the errors. USB adaptors have their own code on them to
access the drives, and you are at their mercy for what they can and can
not do. They are great for the field in a pinch, but they are not good
for hard core data recovery. If you really want to know what is going on
with a drive, hook it direct to the computer.
So now I have to ask, are you using the USB bridge for these tests? If
you have the drive hooked directly to the computer and you still notice
the slowdown with the --direct option, then maybe ddrescue could use to
be changed. But if you are basing this all on a USB adaptor, then
ddrescue might not need to be changed at all.
Scott D.
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
