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 _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
