Re: [bug-ddrescue] ddrescue strange read behaviour

[Rog Fanther]

Your hard disk gets into an error condition when trying to read some very 
bad patch of sectors, and drops offline.
You could reduce the timeout and number of retries, so that ddrescue doesn?t 
try too much to read bad sectors at the first pass, or if the bad patch is 
contained into a small area, try to skip that area and read the rest of the 
disk.

Or, get ready to disconnect/reconnect power to the disk ( a switch in the 
middle of the power cord helps ) and re-detect it into the sata controllers.

Just keep in mind that trying too much to read those bad sectors can damage 
the heads, then things get wor$e.

[ ]
----- Original Message ----- 
From: "Marco Marques" <address@hidden>
To: "Antonio Diaz Diaz" <address@hidden>
Cc: <address@hidden>
Sent: Friday, January 10, 2020 6:09 PM
Subject: Re: [bug-ddrescue] ddrescue strange read behaviour


Hi Antonio,
   in order to answer a litle more about the reading issues I am facing,
here are the kernel ATA messages that I got in this particular HDD.

   [ 1.078615] ata7: SATA max UDMA/133 abar m512@0xf7a10000 port
0xf7a10100 irq 41
   [ 1.551176] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
   [ 1.553009] ata7.00: ATA-8: ST31000340AS, SD1A, max UDMA/133
   [ 1.553012] ata7.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32)
   [ 1.555255] ata7.00: configured for UDMA/133
   ....
   [ 106.013191] ata7.00: READ LOG DMA EXT failed, trying PIO
   [ 106.032859] ata7: failed to read log page 10h (errno=-5)
   [ 106.032907] ata7.00: exception Emask 0x1 SAct 0x8000 SErr 0x0 action 
0x0
   [ 106.032947] ata7.00: irq_stat 0x40000008
   [ 106.032974] ata7.00: failed command: READ FPDMA QUEUED
   [ 106.033010] ata7.00: cmd 60/00:78:00:54:ab/04:00:2c:00:00/40 tag 15
ncq dma 524288 in
   [ 106.033095] ata7.00: status: { DRDY }
   [ 106.066187] ata7.00: both IDENTIFYs aborted, assuming NODEV
   [ 106.066190] ata7.00: revalidation failed (errno=-2)
   [ 106.066233] ata7: hard resetting link
   [ 106.534514] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
   [ 106.557603] ata7.00: both IDENTIFYs aborted, assuming NODEV
   [ 106.557606] ata7.00: revalidation failed (errno=-2)
   [ 111.721004] ata7: hard resetting link
   [ 112.190978] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
   [ 112.221389] ata7.00: both IDENTIFYs aborted, assuming NODEV
   [ 112.221392] ata7.00: revalidation failed (errno=-2)
   [ 112.221433] ata7.00: disabled
   [ 112.221469] ata7: EH complete

   This is the result in the JMicron controller...
   As soon as I have the time to get the in th Intel I will report them
here ...

   Thanks in advance ...
   Marco Marques

   Citando Antonio Diaz Diaz <address@hidden>:
> Hi Marco,
>   Marco Marques wrote:  > In the Intel once a bad read sector is  found I 
> get several "Kernel ATA"
> >    errors and ddrescue continues to try to read.
> >    Despite the fact the HDD is now "offline and out of the system",
> >    ddrescue tries to continue with no sucess.
>   After every read error ddrescue verifies that the input file is  still 
> there. If the name exists and the read() call does not set  'errno' to 
> EINVAL, ddrescue continues reading. Maybe ddrescue should  also stop on 
> EBADF and maybe on ESPIPE and ENXIO? (I have no idea  what value the 
> device driver will return to mean that the drive is  "offline and out of 
> the system").
>
> > In the Jmicron controller I get different situation :
> >    Although still getting the same "Kernel ATA" errors but now ddrescue
> >    aborts with :
> >    "ddrescue: Unaligned read error. Is sector size correct ?"
>   This is because in this case read() is setting 'errno' to EINVAL,  which 
> in direct mode usually means an incorrect sector size.
>
> > So in order to proceed I have to completly shutdown the system in order
> >    to access the HDD and proceed with the data recovery .
> >    ( Rebooting does not allow the system to recover access to the HDD 
> > ...)
>   I think drescue can't help here.
>
> > With this specific HDD I did found some other strange behaviour where
> >    the -i flag was being ignored ...
> >    In one of the trials I call the "-i 500GiB" but ddrescue simply 
> > ignored
> >    it as it started to read from a lower value
>   This is a bug in ddrescue. As you can read in the manual:
>
> http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Basic-concepts
>   "Ddrescue will never try to read any data outside of the rescue  domain 
> except when unaligned direct disc access is requested (see  Direct disc 
> access). If it does, please, report it as a bug."
>
>   Please, try to reproduce the problem using the option 
> '--log-reads=FILE', and then send me the exact command line you used  and 
> the FILE (compressed) so that I can find out what the problem  is. Thanks.
>
> > Is the "-s" flag mandatory ?
>   No. If you do not specify a size, ddrescue reads up to the end of the 
> file.
>
> > Before ddrescue aborts I get "read errors: yyy " but in the next
> >    ddrescue call it becomes 0 .
> >    it would be useful to have some kind of totaliser (failed , read 
> > error )
> >    as also have some kind of human readable info
> >    ( number of opening tries to the file ) in the mapfile related to
> >    previous ddrescue calls .
>   This requires a change of format in the mapfile and may be  confusing or 
> even annoying. For example, if "read errors:" keeps the  previous value, 
> the 'N' in '--max-read-errors=N' needs to be  increased in each call. (Or 
> the syntax of 'N' be also changed). So  it needs some justification and 
> careful thinking.
>
>
>   Best regards,Antonio.