Re: [Bug-ddrescue] BUG this time... -J doesn't always work :(

[Webbed . Pete]

Here's a real-world example of how this bug can lead to errors in data recovery:

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