Hi Eirik,
Eirik Øverby wrote:
This is in fact a success story (see end of message), but: I was trying
to rescue data from a Quantum Fireball SCSI drive today, and experienced
a peculiar problem. After lots of "interesting" noises and a few dozen
MBs into the rescue process, the disk decided to spin down. It was still
attached to the bus. The weird part is that ddrescue kept getting data
from it - presumably zeroes? and though all was well. This also applied
during phases 2-5 when it went back to read the bad/skipped parts - I
ended up with a 100% recovery rate but most of the result was obviously
empty.
I think several people in this list have seen the behavior you describe.
This is why ddrescue provides the option '--verify-on-error':
http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue
-J
--verify-on-error
After every read error, read again the last good sector found and
verify that it returns the same data. Exit with status 2 if the read fails
or returns inconsistent data. Exit with status 1 if a read error happens
before a good sector is found.
This option performs one extra read after each error, wearing the drive
faster. Use it only on drives that stop responding or return garbage data
after finding errors. You may need to power cycle the drive before
restarting ddrescue.
I was not using any special options to ddrescue except -r1. I did _not_
operate in direct IO mode on the first pass - I'm not even sure it makes
a difference.
In my case, using direct input mode (--idirect) solved the problem with a
USB memory stick.
Best regards,
Antonio.
