Re: [Bug-ddrescue] GNU ddrescue 1.18-pre3 new option complication

[Sam]

Hi Antonio,

----- Original Message -----
From: Antonio Diaz Diaz

> Scott D wrote:
>> Might have found a sligh flaw with the "-O" option idea. The flaw is
>> that it does not take an actual error (at least not one that ddrescue
>> sees) to cause the slowdown. If there are difficult spots on the disk
>> but no reported errors, it can still cause the reads afterwards to
>> reduce speed.
>
> If it helps, it is certainly possible to make ddrescue reopen the file
> after one or more slow reads.
>
> Of course I would prefer to see the kernel fixed, or at least a
> explanation of why it slows down after an error.

FYI this is actually a deliberate action by the Linux kernel (and by some other 
Unix derivatives, and by Windows, but I don't know about OSX on Macs) when some 
disk drive errors occur. It is not a bug, as it is intended behaviour. 


The intent is that for normal situations, it is preferred by users for their OS 
not to totally give-up all access to a disk which has a marginal problem (which 
would therefore prevent any access to their data, or perhaps to the OS itself 
thereby causing a crash). Instead the OS (e.g. in modern Linux kernels it will 
be libata, in different Unix versions the relevant drivers vary) will reduce 
the SATA link speed and/or the ATA transfer mode (which still affects SATA 
drives), to try to keep some (slower) I/O access going to such a disk. 

To give an example in the current (3.10) Linux kernel source code, the 
ata_eh_speed_down_verdict function in libata-eh.c is part of the relevant 
error-handling code:

http://lxr.free-electrons.com/source/drivers/ata/libata-eh.c#L1894

As is explained by the comments for that routine, depending on the exact 
details of previous disk-related errors and 
how recently to the "current" error they occurred, then the I/O speed 
reduction which I explained above might be triggered by ata_eh_speed_down, 
based on the decision from ata_eh_speed_down_verdict. Different OS, different 
Linux kernel versions, (especially those which precede libata being 
introduced), may have different criteria to trigger a speed reduction, as 
error-recovery algorithms vary. And, as I mentioned, it also depends on the 
specific disk errors in the first place.

This raises the obvious question about whether there is an easy way (e.g. 
without recompiling the kernel) to influence or reverse this behaviour, if 
wanted, under user control. I haven't yet looked into this, but I suspect the 
possibilities to influence this easily (if there are any at all) will also vary 
depending on OS, kernel version, and more especially for pre-libata.


Hope that starts to answer your question, but I know we'd all prefer a 
different situation. :-)


Sam