Mdthbs

This question addresses the first pass of ddrescue on the device to be rescued.

I had to rescue a 1.5TB hard disk.

The command I used is:

# ddrescue /dev/sdc1 my-part-img my-part-map

When the rescue is started (with no optional parameters) on a good
area of the disk, the read rate ("current rate") stays around 18 MB/s.

It occasionally slows a bit, but then comes back to this speed.

However, when it encounters a bad area of the disk, it may slow down
significantly, and then it never comes back to the 18 MB/s, but stays
around 3 MB/s, even after reading 50 GB of good disk with no problem.

The strange part is that, when it is currently scanning a good
disk area at 3 MB/s, if I stop ddrescue and restart it, it restarts at the higher reading rate of 18 MB/s. I
actually saved about 2 days by stopping and restarting ddrescue
when it was going at 3 MB/s, which I had to do 8 times to finish the first pass.

My question is: why is it that ddrescue will not try to go back to the
highest speed on its own. Given the policy, explicitly stated in the documentation, of doing first and fast the
easy areas, that is what should be done, and the behavior I observed
seems to me to be a bug.

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?

Still, even with an option to specify it, I am surprised this is not done by default.

Meta note

Two users have voted to close the question for being primarily opinion
based.

I would appreciate knowing in what sense it is?

I describe with some numerical precision the behavior of an
important piece of software on an actual example, showing clearly that
it does not meet a major design objective stated in its documentation
(doing the easy parts as quickly as possible), and that very simple
reasoning could improve that.

The software is well know, from a very trusted source, with precise
algorithms, and I expect that most defects were weeded out long ago.
So I am asking experts for a possible known reason for this unexpected
behavior, not being an expert myself on this issue.

Furthermore, I ask whether one of the options of the software should
be used to resolve the issue, which is even more a very precise
question. And I ask for a detailed aspect (how to choose the parameter
for this option) since I did not find documentation for that.

I am asking for facts that I need for my work, not opinions. And I
motivate it with experimental facts, not opinions.

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.

@babou I don’t have sufficient ‘reputation’ to upvote your question. I tried to and found that I cannot. I found your question after experiencing the exact behaviour you described. It is clear to me that the people who think your observations are ‘opinion’ are wrong, and wrong with Mathematical certainty. They should be congratulated for achieving maximum wrongness. Your valid statements asking why this is in an opinion have gone unanswered which is a pity as that is exactly the question I would have asked. My opinion (and it is more a guess) is that people are close minded to things they don’t want to believe (for example climate change denial) and simply discard new information that doesn’t fit their model of the world. You have stated an observable fact. An apple falls down from a tree is now an opinion?

Sorry that my two-cents worth is much too late to be useful to you but I thought that (a) I would like to let you know that you have been wronged (that is a fact, not an opinion) and (b) having seen exactly what you describe, I have something that remedies the problem, at least for me on this occasion. I used the –d switch on the command line aka ‘direct disk access’.

Now –d is a remedy (not necessarily a solution), but it is not an explanation. Sorry I don’t have that. All I know at this time is that I had your problem, and –d is a remedy and working pretty much how you described (sarcasm mode on) ‘in your opinion’ (sarcasm mode off) you would expect ddrescue to work. I am doing a disk recovery using system-rescue-cd and even with the output file as /dev/null, I see the behaviour you reported.

BTW in my current problem, the 'current rate' drops from 100MB/s to 60MB/s so the difference is signifcant. With -d, this saves more than one hour on 1TB disk.