Hi Stefan,

Stefan Monnier wrote:
- The estimated remaining time should be more conservative.

It is difficult to make predictions, especially about the future. :-)

While developing ddrescue, I noticed that the current rate is too volatile, but the average rate may take a long time to reflect changes in speed, especially after a change of phase.

So I use the average rate of the last 30 seconds to estimate the remaining time. If your rescue is having slow fluctuations of speed, ddrescue will probably show fluctuations in the remaining time. Maybe increasing the interval to the last 60 seconds could dampen such fluctuations, but would also increase the amount of calculation involved.

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 imprecise, may vary widely during the rescue, and may show a nonzero 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.

- I think it'd be useful to be able to say `--size input` and `--size
   output` to tell ddrescue to use as size the size of the given
   input resp. output.
   Example case for using the output size:

       ddrescue --force --size output /dev/urandom /dev/mydisk mydisk.map

'--size=input' is not needed because it is the default behavior of ddrescue (when lseek returns the true size), but '--size=output' is indeed useful when overwriting the output file or device. Thank you for the suggestion. I'll implement it for the next version, to be released in January.

In any case, I'll take this opportunity to thank you for this neat tool,
which is surprisingly more flexible than I expected (especially thanks to
the `-F` option).

My pleasure! :-)

Best regards,
Antonio.

Reply via email to