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" <>
To: "Antonio Diaz Diaz" <>
Cc: <>
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 <>:
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:
"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.

Reply via email to