[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.