Re: [Bug-ddrescue] --input-position and --min-read-rate parameters ignored

[Antonio Diaz Diaz]

Florian Sedivy wrote:
> So how to reset the current position to 0 without editing the log 
> file? -M --retrim and -A --try-again do that I think, but one might 
> not want to manipulate the status. Antonio once posted a trick 
> involving an intermediate fake run with -s 0. - Does such a trick 
> still work? (I tried it once, and it didn't.)

Sure it didn't work; '-s0' is an empty domain.

For the trick to work, ddrescue needs to have something to do at the 
specified position. Else, what is the point of changing it?

Try 'ddrescue -i<pos> -s1 -r1', and if <pos> is not already rescued, 
ddrescue will change the current position to <pos>.


> (Does -L --loose-domain ignore the current position from the log
> file?)

No, it should not ignore it.


> Julien, you can use -Nn (--no-trim --no-split) to stop ddrescue after
>  the copying phase and repeatedly try to clone easy areas first. You
>  might decrease the --min-read-rate each time to move from the
> fastest to slower areas, if that helps in your case.

Or use '--min-read-rate=0' for automatic adjusting to the average read 
rate. But remember that --min-read-rate is only used during the copying 
phase.


> Some additional questions to Antonio though: - A single read
> operation is _never_ timed out by ddrescue itself, right?

Right.


> Is the calculation for --min-read-rate in v1.18.1 more fine-grained
> than one-second-averages, like proposed in the thread for 1.18-pre3?

Not yet.


> Is the response-time of errors factored in or ignored when
> calculating for --min-read-rate?

Ignored. The calculation is simply (bytes_copied / time).


> As skipping is disabled in the sweeping pass, does -a --min-read-rate
> have any effect in the third pass of the copying phase?

No.


Best regards,
Antonio.