On Tue, Jun 18, 2013 at 08:37:36PM +0200, Antonio Diaz Diaz wrote: >> Retrying non-stuck sectors on the spot wouldn't hurt.
> Maybe it doesn't hurt but, have you verified that it does indeed > make some good? On Thu, Jun 27, 2013 at 05:30:30PM +0200, Antonio Diaz Diaz wrote: > It seems that retrying the same sector several times in a row is > mainly a waste of time. I have been able recover some (70 sectors, when 99.996% rescued) bad sectors by increasing the timeout to 5 minutes on v3.2 kernel and thus increasing the retry count to 35 on each sector. Possibly the same amount of bad sectors could have been recovered and approximately same amount time by running 35 separate passes Ddrescue over them. I have tried to do bad block multi-sampling from user space, but the kernel does not return data from bad sectors. Maybe the driver could be hacked to be more generous? SpinRite claims it can fetch data even from bad sectors and to use statistical analysis on them. SpinRite uses Bios calls to read the bad sectors. When I tried it, SpinRite couldn't recover the bad sectors perfectly, only partially. And it didn't say which bits were corrupted which were not. And it didn't save statistics or samples and wrote over the bad sector. It tries to read the sector 2000 times. For me the cycle time was 16 seconds and 2000 retries makes 9 hours. It uses head wiggling to try increase the chance that drive can read itself the sector correctly. Judging from the hard drive sounds it seems the drive itself is using this when reading with ddrescue. What was interesting is that the number of unique samples per sector was quite low, usually less than 30. I is as if only 5 bits or less were unstable and breaking the ECC. Knowing which bits are corrupted would make data recovery much easier. Too bad SpinRite doesn't say which. Maybe it doesn't know for sue and only guesses. Jarkko Lavinen _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
