Re: [Bug-ddrescue] How to increase retries within a pass?

[Jarkko Lavinen]

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