[Bug-ddrescue] Another bug on -J drives: trim mode is actually scrape mode

[Webbed . Pete]

Here's another scenario where -J fails to work correctly.

Context:
- Doing data recovery on a drive that needs the -J switch (i.e. once a
hard error is found, it no longer returns data until power cycled.)
- The drive has been correctly power cycled and thus is able to return
good data

Scenario:
1) We're in Phase 2 Trimming (*) mode
2) Assume a block sequence of: + * +  (ie a block with a "hidden" bad sector, 
surrounded by good data)
3) What should happen: read front of non-trimmed block until a bad sector, then 
end of 
block until bad sector.

What actually happens:
- The front is read until a bad sector, which locks the drive
- This first run expands the previous '+' block
- Next run (after drive restart and ddrescue restart) gets no data and the bad 
sector is 
marked (Now we have: + - * +)
- Next run **continues from the front** and either finds new good data or adds 
another 
bad sector to the '-' block
- And so forth. *** end of block is never trimmed; this is effectively scrape 
mode ***

If we try using -R reverse, it **still** trims from the front of each block. 
Reverse 
apparently only affects block sequences, not what happens within a block, at 
least in trim 
mode.

Thanks much,
Pete




Scenario (just happened to me)
1) ddrescue's first read is of a bad block
2) [The drive now will no longer read even good data]
3) ddrescue does not test the drive, because there has not been a read
of a good data 
block
4) ddrescue will now mark ALL reads as bad blocks until it is
stopped.

Thus, because of this bug, ddrescue can easily and incorrectly mark
huge swaths of a 
drive as having bad blocks.

Antonio, your first caution is true, yet it also applies to the -J
switch as currently 
implemented. There is never a guarantee that any block will remain
"good".

(I assume you meant to say that outfile is opened "write-only"? But
not a big deal to 
open it for read-write)

A simple suggestion: if I *know* the drive acts this way, what if the
user could provide a 
switch to say it has this characteristic. Then, the app could just act
as if -J had failed 
whenever there's a read error.

More complex idea... a slightly improved -J test algorithm might help
cover all cases?

Thanks,
Pete


PS Thinking through a more robust read-after-error test...
//
// only use this after a read error
//
function CanDriveStillReadAfterReadErr()
        Static Enum DriveCanReadAfterReadErr= Unknown; // {No, Yes,
Unknown};

  If (No == DriveCanReadAfterReadErr) {
        N = 1;  // OR -- don't even test. If we know it doesn't work, why 
not
quit now?
  } else {
        N = 2; // 4?? Seems unlikely that a lot would go bad?
  }
        
  For up to N previously readable sectors {
     Attempt to read a sector;
     If (readable and matches) {
        DriveCanReadAfterReadErr = Yes;
        Return True;
     } else {
        If (No == DriveCanReadAfterReadErr) {
   Return False;
           }
        If (Yes == DriveCanReadAfterReadErr) {
                     Mark Sector BadAfterGood;
           }
     }
  }
//
// Fell through.
// This means we failed N sectors that previously were OK 
// Probably best to conclude that this does NOT work!
  DriveCanReadAfterReadErr = No;
  return False;
}


On 15 Dec 2015 Antonio Diaz Diaz said...

>Hello,
>
>Pete Holzmann wrote:
>> -J seems to only work correctly if, in the *current run* there
has
>been a 
>> successful read.
>
>True.
>
>
>> But once I power cycle the drive and restart ddrescue, it will
run
>for minutes 
>> or hours without ever stopping.
>> 
>> Shouldn't it, after seeing an error, go to ANY
>already-known-good-block and do a 
>> test read to ensure the drive is still responsive?
>
>It could, but this would have some drawbacks:
>
>- It complicates the code because there is no such thing as an 
>"already-known-good-block"; any block succesfully read in a
previous
>run 
>may be unreadable now.
>- Data consistency can't be verified unless the data is also read
>from 
>outfile, which ddrescue currently opens read-only.
>
>Does anybody think that this change is worth the trouble?
>
>
>Best regards,
>Antonio.



_______________________________________________
Bug-ddrescue mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ddrescue