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

I think several people in this list have seen the behavior you describe. This is why ddrescue provides the option '--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,

Reply via email to