On 17.06.2014 00:56 Robert Backhaus <[email protected]> wrote: > On 16 June 2014 18:55, <[email protected]> wrote: > >> Hello, >> >> - i : --input-position : starting position in input file >> >> This parameter is buggy : it is taken into account only when its value >> is larger than the current input position. If one want to use an offset >> that is smaller than the current position, one first have to the value >> for "-i" near the end of the drive in order to finish the cloning. Then >> only, we can start the cloning again with a smaller "-i" value. > > No, this is the correct operation of -i, and it is not ignored. If you > specify -i, ddrescue will not attempt any rescues before that value. It > will not jump back and start trimming bad blocks or reading in a different > location immediately. This is by design. > In other words, -i --input-position does not set the current position, but the start of the rescue domain.
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.) - Could there be a more straightforward way to let ddrescue ignore or set the current position? (Does -L --loose-domain ignore the current position from the log file?) >> >> -a / --min-read-rate : Minimum read rate of good areas in bytes/s >> >> I tried setting it to "-a 20000", but I still oberve very slow reading >> rates, sometimes of only 256 B/s. >> I hoped that setting "-a" would help speeding up ddrescue and clone the >> easier areas first. >> But after several passes, the software is trimming failed blocks and the >> speed is much slower than thus set by "-a". >> I'm not sure if the value of "-a" is ignored or if there is something >> that I did not understand. > > -a cannot prevent slow reads from happening. When there is a slow read, it > considers it as an error and jumps to another location to find data it can > retrieve faster. Blocks skipped because they are slow are then read before > the trimming stage, and -a is not considered during trimming, as slow reads > and errors are expected then. This is outlined in the info file for > ddrescue. > 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. Just to clarify: slow reads are not considered an error, except they actually return an error. Slow reads just trigger skipping after being processed normally. Some additional questions to Antonio though: - A single read operation is _never_ timed out by ddrescue itself, 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? - Is the response-time of errors factored in or ignored when calculating for --min-read-rate? - As skipping is disabled in the sweeping pass, does -a --min-read-rate have any effect in the third pass of the copying phase? Florian > Robert >> Julien _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
