Re: [Bug-ddrescue] Suggestion: Remaining time

[Antonio Diaz Diaz]

Hello David,

David Morrison wrote:
> I am just copying a disk with a number of bad blocks near the end.
> Initially, the Remaining time estimate was 9 hours, but once it hit the
> bad block, the estimate is all over the place, from 1 hour to 15 days. I
> guess it is based on an average of how much has been transferred in the
> last x seconds.

You are right:

http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Output
remaining time
    Estimated remaining time to rescue all the data in the rescue 
domain. The remaining time is calculated using the average rate of the 
last 30 seconds and does not take into account that some parts of the 
rescue domain may be excluded from the rescue (for example with 
'--no-trim'), or that some areas may be unrecoverable. Therefore it may 
be very imprecise, may vary widely during the rescue, and may show a 
non-zero value at the end of the rescue. In particular it may go down to 
a few seconds at the end of the first pass, just to grow to hours or 
days in the following passes. Such is the nature of ddrescue; the good 
parts are usually recovered fast, while the rest may take a long time.


> So my suggestion is that maybe basing it on the average amount
> transferred over the last x seconds may not be helpful when there are a
> lot of bad blocks in an area of the disk. (I would guess that bad blocks
> are more likely clustered together than scattered randomly over the disk.)

The bad blocks are sometimes clustered together and sometimes scattered 
randomly. It depends on the kind of damage.


> Perhaps some calculation that incorporates how many failed reads there
> have been in the last y seconds as well as how much has been transferred
> may be more useful?

Maybe. "current rate" and "average rate" already help to guess if 
ddrescue is in a slow area. Suggestions are welcome. Perhaps ddrescue 
could show in addition to the current remaining time an "average 
remaining time" taking into account the time elapsed since the beginning 
of the current run instead of the last 30 seconds. In any case, any 
calculations involved must be efficient because they are redone every 
second.


Best regards,
Antonio.