bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-ddrescue] ddrescue strange read behaviour


From: Antonio Diaz Diaz
Subject: Re: [bug-ddrescue] ddrescue strange read behaviour
Date: Tue, 18 Feb 2020 17:42:33 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14

Marco Marques wrote:
The idea of a counter in the mapfile it might be useful in case of tests
and trials ( as I am currently ) where each time I get an error the
ddrescue simply exits writing the file .
As sometimes  try a new zone I  copy the full domain mapfile aside and
make some tests , returning to it later  , still keeping writing to the
same fullfile ....
In this case the datestamp is not enough to aid ...

If the timestamp is not enough ¿?, then you may devise a naming convention for test mapfiles that allow you to keep track of what you have done. Making a backwards-incompatible change to add a counter seems too much truble.


Although this weekend I started fiddling a little bit with the "-b " flag
, order to mark some bad parts ...
As far as I tried it is working as expected as I get more bad blocks
marked faster ( bigger volume ) at the expense of not recovering the data.
Can I use that way or I am doing it completly wrong ?

You are doing it completely wrong. :-)
'-b' must be (a multiple of) the real sector size, or all reads will instantly fail in direct disc access mode.


Another comment is the "-i" only after several analysis I have found that
ddrescue starts to read in the next domain mapfile section, explaining why
if I call "-i 4G" ddrescue started to read at the "9G" section.

This should not happen. If there is a pending area at pos X, '-i X' should try to read it. Please verify the exact numbers you pass to -i.


Another detail, refering the "line type runtime map" I understand the
difiiculty of condensing the million datablocks but the idea would be to
have a visual aid even it would be rough with at least the reading position
in the full domain mapfile would be nice...

OK. I'll see what I can do.


Best regards,
Antonio.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]