Re: [Bug-ddrescue] ddrescue stalling

[Antonio Diaz Diaz]

Florian Sedivy wrote:
> Using ddrescue on several occasions I noticed that more often than not a
> damaged drive would just stall the reading process for hours (maybe forever)
> instead of returning an error.

Ddrescue takes the safe and portable approach; asks the kernel to read a 
chunk of data and waits until the kernel returns the data or an error. 
Setting a timeout is not as good idea as it may sound. If the drive or 
the kernel are busy retrying, ddrescue can't do other thing but wait.

You may try raw devices or the latest developmet version of ddrescue, 
which implements direct disc access, avoiding the kernel caching. Of 
course this won't help you if the drive itself stalls and the kernel 
doesn't implement a timeout.


> ddrescue sometimes updates display about every 30 seconds, giving also the
> opportunity to abort with ctrl-c. Most of the times however ddrescue will be
> as unresponsive as the drive and the only way out is to force an error by
> removing the device.

Perhaps making ddrescue multithreaded would make it more responsive, but 
less stable and portable. I have to take a look at this.


> Of course there are a lot of other problems associated with this:
> What should ddrescue do when the timeout is reached, except to obviously
> treat it as an error?

Obviously, treat it as an error.


> Will it be able to abort the read-operation on the drive and move on to the
> next (possibly also stalling) chunk, or will the drive just remain
> unresponsive still trying to deliver the last chunk?

I suspect the only sane thing ddrescue can do when the timeout is 
reached is terminate.


> Can ddrescue know the difference?

No.


> Can ddrescue reset the device to allow further operations?

No. That implies specialization for some devices or interfaces.


> Will all this be consistent between platforms?

Most probably not.


> Does the behavior change in direct- or raw-modes?

Sure, but the change depends on the kernel.


Regards,
Antonio.