[Bug-ddrescue] Getting out of error areas faster

[Antonio Diaz Diaz]

Hello Dave,

Dave Burton wrote:
> (Note: I might be confused about the best way to use ddrescue,
> and specifically the "-c" parameter.  Am I right in believing
> that -c sets both the read chunk size and the amount by which
> ddrescue skips ahead on errors, and that these are always same
> number?)

You are right. The "read chunk" size, named "copy block", is c times b. 
That is, the "-c" parameter multiplied by the "-b" parameter.


> The problem is that when it hits bad sectors, it becomes
> excruciatingly slow.  It appears to me that either the
> Linux disk buffering code or else the drive firmware
> tries to read every sector in the big blocks, even after
> one of those sectors fails.  Can that be right?

I think you are right. But reality may be even worse. When ddrescue asks 
linux to read 1 sector in a floppy with many errors, the floppy driver 
tries to read even more than 300 sectors! The kernel does not return 
until it finishes this unrequested reading frenzy, so ddrescue is 
blocked for all this time.


> SUGGESTION #1:
> So what I'd like is a way to make ddrescue switch modes
> automatically, based on the progress it is (or is not) making.
> This amounts to a "smart" (automatically self-adjusting) setting
> for the "-c" (and "-d") parameters.

Switching to small size reads is what dd_rescue does, and I don't like 
it because it means spending more time at error areas instead of getting 
out of them as fast as possible.


> SUGGESTION #2:
> If a read (whether large, or 4K, or one sector) is successful,
> the next read should immediately follow it.  However, if
> several successive reads fail, it would be useful to have
> ddrescue be able to "skip ahead" by progressively larger
> and larger numbers of sectors, trying to pass over the bad
> area as quickly as possible, to find and read as much of the
> good areas as possible as quickly as possible.

Ddrescue already attempts to read the first sector of every "copy 
block", and only reads the rest of the block if it could read the first 
sector successfully. But I suspect that kernel or drive read ahead don't 
let this work as it should.

I have implemented a "variable skip ahead" mode in version 1.6-pre4 (not 
yet released). It works as usual until it finds two consecutive errors, 
then skips ahead for an amount that increases by one "copy block" with 
every new error, until it is able to read a whole "copy block" without 
errors.

I am busy working on the manual now, but if you or someone else in this 
list want to test it I can make a release tonight.


Regards,
Antonio.