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

[Florian Sedivy]

On 17.06.2014 00:56 Robert Backhaus <address@hidden> wrote:

> On 16 June 2014 18:55, <address@hidden> 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