Re: [bug-ddrescue] ddrescue strange read behaviour

[Marco Marques]

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.