sorry for  the delayed answer...
 After some tests I am using only the Jmicron SATA controller as it fully
stops when it reads an error .
 In attach are the ddrescue readlog file and the map file for the full HDD

 Although because the readlog file i s so small here it is : 
 # Reads Logfile. Created by GNU ddrescue version 1.24
 # Command line: ddrescue -r 1 -O -d -c 10M --log-reads=ddrescue.log
/dev/sdb /mnt/mk1/marcio1Tb.hdd marcio3.map
 # Start time:   2020-02-10 20:28:33
 #  Ipos       Size  Copied_size  Error_size
 # 0s  Scraping failed blocks... (forwards)
 0xC9EFBC00    512    0    512
 # 9s
 0xC9EFBE00    512    0    512
 0xC9EFC000    512    0    512
 0xC9EFC200    512    0    512
 0xC9EFC400    512    0    512
 0xC9EFC600    512    0    512
 0xC9EFC800    512    0    512
 0xC9EFCA00    512    0    512
 0xC9EFCC00    512    0    512
 0xC9EFCE00    512    0    512
 0xC9EFD000    512    0    512
 0xC9EFD200    512    0    512
 0xC9EFD400    512    0    512
 0xC9EFD600    512    0    512
 0xC9EFD800    512    0    512
 0xC9EFDA00    512    0    512
 0xC9EFDC00    512    0    512
 0xC9EFDE00    512    0    512
 0xC9EFE000    512    0    512
 0xC9EFE200    512    0    512
 # End time:     2020-02-10 20:28:42
 So as far as I can see nothing out of the ordinary ....

 Although ddrescue exits with the read error message and the HDD
"disappears" from the system ...
 If I try to run imediatly I get the "no medium available" message as

 Relating to the "-i" flag please ignore my previous reference as I noticed
that the strange behaviour were related to the -"R" flag ...

 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 .

 I am still recovering the same HDD that each time it gets to a incorrect
read error it "disappears" from the system and ddrescue exits .
 In order to power cycle the HDD I build a manual power switch to the HDD
to help with the recovery.

 Nonetheless I do need some help as if I use the "-M" flag I loose all the
bad blocks found previously ... :(

 In this latest experience (a 1Tb HDD), in a initial approach I had 9Gb at
the trimming part,
  afterwards applied the "-A" and "-M" flags it decreased to the 6Gb and
now after some more tries I get 2.5Gb .
 Although the ammount of bad blocks is still in the 100Kb amount ...

 So my question is : am I doing the right thing by using the "-M" flag ?
 or is there any other form to keep the badblocks marked ?

 Another detail is related to the "-K" flag ... Is it applied in the
Trimming or Scrapping phases ?
 Although I am tented to edit manually the mapfile I will try to avoid it.

 Changing subject I think that the information os the status could be
improved a litle bit.

 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 :
 Updated at the same time as the main status interface .
 ( the symbols could be the same as mapfile in order to keep consistency )

 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 .

 THanks in advance
 Marco Marques

Attachment: ddrescuelogs.7z
Description: Binary data

Reply via email to