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.