Re: [bug-ddrescue] ddrescue strange read behaviour

[Antonio Diaz Diaz]

Hello Marco,

Marco Marques wrote:
> Nonetheless I do have some other details to ask :
> if there is a way to keep the marked bad sectores when "clearing" the
> trimming phase "-M" flag .

The goal of the '-M, --retrim' option is to mark all failed blocks inside 
the rescue domain as non-trimmed in order to try them again. If you want to 
try them again without unmarking them, you may use '--retry-passes=1'. See
http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Invoking-ddrescue


> Another detail is related to the "-K" flag ... Is it applied in the
> Trimming or Scrapping phases ?

Ddrescue only skips during the copying phase. It does not make sense to 
blindly skip ahead when the bad areas have already been delimited. See 
http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Algorithm

2) (First phase; Copying) Copying is done in up to five passes. The first 
pass reads the non-tried parts of the input file, marking the failed blocks 
as non-trimmed and skipping beyond them. The second pass delimits the blocks 
skipped by the first pass. The first two passes also skip beyond slow areas. 
The skipped areas are tried later in one or three additional passes (before 
trimming). The copying direction is reversed after each pass until all the 
rescue domain is tried.


> Although I am tented to edit manually the mapfile I will try to avoid it.

You do not need to edit the mapfile manually. Instead use the domain setting 
options (-i and -s) to restrict the rescue to the area of interest.


> An idea would be to use something like a "status" bar ( something like a
> line 80 columns ) with some info to give a rough idea where the current
> reading place is being done.
> Something like this :
> .......-............R..........*...........+...................................

Marking the current reading place is easy. The problem is deciding what to 
print in the other 79 columns, given that each character must condensate the 
status of (in your case) 25 million sectors.


> Another detail that might be usefull in the mapfile would be somekind of a
> counter, indicating how may times the file was written or similar .

What would be the use of this feature?


Best regards,
Antonio.