Why is ddrescue slow when it could be faster on error free areas?

I have been wondering whether this can be dealt with with the option -a or --min-read-rate= ... but the manual is so terse that I was not sure. Besides, I do not understand on what basis one should choose a read rate for this option. Should it be the above 18 MB/s?

The --min-read-rate= option should help. Modern drives tend to spend a lot of time in their internal error checking, so while the rate slows down extremely, this isn't reported as error condition.

even after reading 50 GB of good disk with no problem.

Which also means: you don't even know if there are problems anymore. The drive might have a problem, and decide to not report it.

Now, ddrescue supports using a dynamic --min-read-rate= value, from info ddrescue:

 If BYTES is 0 (auto), the minimum read rate is recalculated every
 second as (average_rate / 10).

But in my experience, the auto setting doesn't seem to help much. Once the drive gets stuck, especially if that happens right at the beginning, I guess the average_rate never stays high enough for it to be effective.

So in a first pass when you want to grab as much data as possible, fast areas first, I just set it to average_rate / 10 manually, average_rate being what the drive's average rate would be if it was intact.

So for example you can go with 10M here (for a drive that is supposed to go at ~100M/s) and then you can always go back and try your luck with the slow areas later.

the behavior I observed seems to me to be a bug.

If you have a bug then you have to debug it. It's hard to reproduce without having the same kind of drive failure. It could just as well be the drive itself that is stuck in some recovery mode.

When dealing with defective drives, you also have to check dmesg if there are any odd things happening, such as bus resets and the like. Some controllers are also worse at dealing with failing drives than others.

Sometimes manual intervention just can't be avoided.

Even then, I am surprised this is not done by default.

Most programs don't come with sane defaults. dd still uses 512 byte blocksize by default, which is the "wrong" choice in most cases... What is considered sane might also change over time.

I am asking for facts that I need for my work, not opinions.

Having good backups is better than having to rely on ddrescue. Getting data off a failing drive is a matter of luck in the first place. Data recovery involves a lot of personal experience and thus - opinions.

Most recovery tools we have are also stupid. The tool does not have an AI that reports to a central server, and goes like "Oh I've seen this failure pattern on this particular drive model before, so let's change our strategy...". So this part has to be done by humans.

this is a bit of a necro post, but for anyone that might happen across this:

I've been able to reproduce OP's behaviour and have gotten ddrescue to resume its maximum read speed by using its -O flag, which reopens the input file after each error.

Unfortunately I haven't had a chance to dig into why it seems to resume at ~3 MiB/s after an encountering an error, but I thought I'd share my experience.