[Bug-ddrescue] Feature Request: Introduce parameter to skip "slow" (still readable) sectors during first pass, if reading speed is below x kByte/s

[Felix Ehlermann]

Hi all!

I've just learned of ddrescue a few days ago - but I'm quite happy that 
I did.
(I got annoyed about dd_rescue getting almost stuck on a group of bad 
sectors about halfway through the drive, slowing down to ~10kByte/s over 
hours).

So far I'm quite impressed by ddrescue - it's really a nice approach at 
recovering data from a broken/dying hard disk, thank your for writing it :-)


About my suggestion (sorry for writing that much, but I apparently am 
unable to explain it in less words):


I have been "enjoying" the opportunigy to observe the recovery process 
of my failing 2 TB HDD over the past days and also used this 
"opportunity" to play around a bit with the --input-position parameter.

I have observed that there sectors on my failing HDD can be categorized 
in these four groups regarding performance:

"good" sectors - they can be read/copied without any IO errors at 
50MByte/s or faster
"slow" sectors - they can be read without any IO errors, but the speed 
is around 1-20 MByte/s
"very slow" sectors - they can be read without any IO errors, but speed 
is <1MByte/s
"bad" sectors - they can not be read and return IO errors, speed

When looking at how they are spread over the drive I noticed, that "bad" 
sectors are virtually always surrounded by a group of "very slow" 
sectors, which itself usually are surrounded by "slow" sectors.

This means that over large percentages of the drive I get data copied to 
my image at almost full speed (50-80MByte/s average).
Then ddrescue runs into a group of "slow" sectors, possibly followed by 
"very slow" sectors, resulting in the "current rate" dropping down for a 
long time (hours) although the affected data area is just a few MBytes 
in size.
Sometimes there's a read error in this slow area and ddrescue will skip 
a few sectors, which is great as it saves a lot of time compared to 
dd_rescue (which would try to read every single sector immediately) - 
but still ddrescue will have to struggle its way through this slow area, 
spending a lot of time there before it will resume with the remaining data.
A few MBytes later there's finally good sectors again which can be read 
at full speed.

I understand that ddrescue already optimizes the recovery by postponing 
reading of damaged areas to a 2nd, 3rd, etc. pass.

It would be really great if there was a way to influence this behavior 
so that e.g. sectors that prove to be slow when reading them (e.g. 
reading 64KiB takes more than 5 ms) will also cause ddrescue to skip x 
MByte of data in the first pass.

Looking at my drive here (and looking back at failed HDs in the past), 
this approach would allow to have a major part of the data recovered 
within just a few hours - which might be crucial when the HDDs state is 
further deteriorating during recovery.


I kind of manually tried to do this by stopping ddrescue (Ctrl+C) and 
starting it again with an incremented --input-position - from my 
impression it would work. But doing this manually is really tiresome.

Having looked at the code a bit, I would assume that implementing this 
into ddrescue might not take too much of an effort (introduce a "slow" 
state for the logfile, measure the time taken by the copy_and_update() 
call, etc?).


Maybe you could give this suggestion a thought or two?


Kind Regards
Felix Ehlermann