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.
_______________________________________________
Bug-ddrescue mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-ddrescue
