[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-ddrescue] --input-position and --min-read-rate parameters ignor
Re: [Bug-ddrescue] --input-position and --min-read-rate parameters ignored
Wed, 18 Jun 2014 11:29:20 +0200
On 17.06.2014 00:56 Robert Backhaus <address@hidden> wrote:
> On 16 June 2014 18:55, <address@hidden> wrote:
>> - 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
>> -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
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
- As skipping is disabled in the sweeping pass, does -a --min-read-rate have
any effect in the third pass of the copying phase?