Read retrys on bad sectors by kernel or drive itself?

[Zuujin]

Hi,
thanks for reading
I hope someone can enlighten me. I'm using GNU ddrescue for friends and family when it comes to harddrives with bad sectors (remapping nasty ones with mhdd or victoria) or sending them to a pro when I see that the problem is out of my league.

I want to reduce stress to the head/surface while imaging with ddrescue, but a closer look at the /var/log/syslog shows clearly that bad sectors are tried to read 6 times:

Mar 7 08:45:30 rescue kernel: [ 1878.837789] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 7 08:45:30 rescue kernel: [ 1878.837793] ata3.00: BMDMA stat 0x5
Mar 7 08:45:30 rescue kernel: [ 1878.837796] ata3.00: failed command: READ DMA
Mar 7 08:45:30 rescue kernel: [ 1878.837802] ata3.00: cmd c8/00:08:d8:a0:97/00:00:00:00:00/e0 tag 0 dma 4096 in
Mar 7 08:45:30 rescue kernel: [ 1878.837804] res 51/40:04:dc:a0:97/00:00:00:00:00/e0 Emask 0x9 (media error)
Mar 7 08:45:30 rescue kernel: [ 1878.837808] ata3.00: status: { DRDY ERR }
Mar 7 08:45:30 rescue kernel: [ 1878.837811] ata3.00: error: { UNC }
Mar 7 08:45:30 rescue kernel: [ 1878.860297] ata3.00: configured for UDMA/133
Mar 7 08:45:30 rescue kernel: [ 1878.860303] ata3: EH complete
Mar 7 08:45:34 rescue kernel: [ 1882.571354] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 7 08:45:34 rescue kernel: [ 1882.571357] ata3.00: BMDMA stat 0x5
Mar 7 08:45:34 rescue kernel: [ 1882.571360] ata3.00: failed command: READ DMA
Mar 7 08:45:34 rescue kernel: [ 1882.571367] ata3.00: cmd c8/00:08:d8:a0:97/00:00:00:00:00/e0 tag 0 dma 4096 in
Mar 7 08:45:34 rescue kernel: [ 1882.571369] res 51/40:04:dc:a0:97/00:00:00:00:00/e0 Emask 0x9 (media error)
Mar 7 08:45:34 rescue kernel: [ 1882.571373] ata3.00: status: { DRDY ERR }
Mar 7 08:45:34 rescue kernel: [ 1882.571376] ata3.00: error: { UNC }
Mar 7 08:45:34 rescue kernel: [ 1882.592294] ata3.00: configured for UDMA/133
Mar 7 08:45:34 rescue kernel: [ 1882.592299] ata3: EH complete
Mar 7 08:45:38 rescue kernel: [ 1886.327168] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 7 08:45:38 rescue kernel: [ 1886.327173] ata3.00: BMDMA stat 0x5
Mar 7 08:45:38 rescue kernel: [ 1886.327177] ata3.00: failed command: READ DMA
Mar 7 08:45:38 rescue kernel: [ 1886.327184] ata3.00: cmd c8/00:08:d8:a0:97/00:00:00:00:00/e0 tag 0 dma 4096 in
Mar 7 08:45:38 rescue kernel: [ 1886.327186] res 51/40:04:dc:a0:97/00:00:00:00:00/e0 Emask 0x9 (media error)
Mar 7 08:45:38 rescue kernel: [ 1886.327190] ata3.00: status: { DRDY ERR }
Mar 7 08:45:38 rescue kernel: [ 1886.327193] ata3.00: error: { UNC }
Mar 7 08:45:38 rescue kernel: [ 1886.348296] ata3.00: configured for UDMA/133
Mar 7 08:45:38 rescue kernel: [ 1886.348307] ata3: EH complete
Mar 7 08:45:42 rescue kernel: [ 1890.071849] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 7 08:45:42 rescue kernel: [ 1890.071853] ata3.00: BMDMA stat 0x5
Mar 7 08:45:42 rescue kernel: [ 1890.071857] ata3.00: failed command: READ DMA
Mar 7 08:45:42 rescue kernel: [ 1890.071864] ata3.00: cmd c8/00:08:d8:a0:97/00:00:00:00:00/e0 tag 0 dma 4096 in
Mar 7 08:45:42 rescue kernel: [ 1890.071866] res 51/40:04:dc:a0:97/00:00:00:00:00/e0 Emask 0x9 (media error)
Mar 7 08:45:42 rescue kernel: [ 1890.071870] ata3.00: status: { DRDY ERR }
Mar 7 08:45:42 rescue kernel: [ 1890.071873] ata3.00: error: { UNC }
Mar 7 08:45:42 rescue kernel: [ 1890.092294] ata3.00: configured for UDMA/133
Mar 7 08:45:42 rescue kernel: [ 1890.092305] ata3: EH complete
Mar 7 08:45:45 rescue kernel: [ 1893.805391] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 7 08:45:45 rescue kernel: [ 1893.805395] ata3.00: BMDMA stat 0x5
Mar 7 08:45:45 rescue kernel: [ 1893.805398] ata3.00: failed command: READ DMA
Mar 7 08:45:45 rescue kernel: [ 1893.805404] ata3.00: cmd c8/00:08:d8:a0:97/00:00:00:00:00/e0 tag 0 dma 4096 in
Mar 7 08:45:45 rescue kernel: [ 1893.805406] res 51/40:04:dc:a0:97/00:00:00:00:00/e0 Emask 0x9 (media error)
Mar 7 08:45:45 rescue kernel: [ 1893.805410] ata3.00: status: { DRDY ERR }
Mar 7 08:45:45 rescue kernel: [ 1893.805413] ata3.00: error: { UNC }
Mar 7 08:45:45 rescue kernel: [ 1893.828298] ata3.00: configured for UDMA/133
Mar 7 08:45:45 rescue kernel: [ 1893.828304] ata3: EH complete
Mar 7 08:45:49 rescue kernel: [ 1897.538956] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 7 08:45:49 rescue kernel: [ 1897.538959] ata3.00: BMDMA stat 0x5
Mar 7 08:45:49 rescue kernel: [ 1897.538962] ata3.00: failed command: READ DMA
Mar 7 08:45:49 rescue kernel: [ 1897.538969] ata3.00: cmd c8/00:08:d8:a0:97/00:00:00:00:00/e0 tag 0 dma 4096 in
Mar 7 08:45:49 rescue kernel: [ 1897.538971] res 51/40:04:dc:a0:97/00:00:00:00:00/e0 Emask 0x9 (media error)
Mar 7 08:45:49 rescue kernel: [ 1897.538975] ata3.00: status: { DRDY ERR }
Mar 7 08:45:49 rescue kernel: [ 1897.538978] ata3.00: error: { UNC }
Mar 7 08:45:49 rescue kernel: [ 1897.560293] ata3.00: configured for UDMA/133
Mar 7 08:45:49 rescue kernel: [ 1897.560303] sd 2:0:0:0: [sdc] Unhandled sense code
Mar 7 08:45:49 rescue kernel: [ 1897.560306] sd 2:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Mar 7 08:45:49 rescue kernel: [ 1897.560310] sd 2:0:0:0: [sdc] Sense Key : Medium Error [current] [descriptor]
Mar 7 08:45:49 rescue kernel: [ 1897.560315] Descriptor sense data with sense descriptors (in hex):
Mar 7 08:45:49 rescue kernel: [ 1897.560317] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Mar 7 08:45:49 rescue kernel: [ 1897.560325] 00 97 a0 dc
Mar 7 08:45:49 rescue kernel: [ 1897.560329] sd 2:0:0:0: [sdc] Add. Sense: Unrecovered read error - auto reallocate failed
Mar 7 08:45:49 rescue kernel: [ 1897.560336] sd 2:0:0:0: [sdc] CDB: Read(10): 28 00 00 97 a0 d8 00 00 08 00
Mar 7 08:45:49 rescue kernel: [ 1897.560344] end_request: I/O error, dev sdc, sector 9937116
Mar 7 08:45:49 rescue kernel: [ 1897.560349] Buffer I/O error on device sdc, logical block 1242139
Mar 7 08:45:49 rescue kernel: [ 1897.560359] ata3: EH complete

This PC is for recovery only, so I wanted to reduce this to 1 try, because I know there will be bad sectors on the attached drives. But where do I change that behaviour?


I read through manpages of ddrescue, hdparm, smartmontools, on various sites on the net and finally I dissected the sourcecode of libata.h/libata.c, scsi.c, and a few more. I found a constant "ATA_EH_MAX_TRIES = 5" as well as "ATA_EH_PMP_TRIES = 5" (PMP = Port Multiplier stuff) in "include/linux/libata.h", but after altering and recompiling the kernel nothing changed.

Digging deeper, I took a closer look at the sense-register where the message "auto reallocation failed" comes from. And now I'm wondering: Maybe the kernel isn't retrying at all? Are the messages from syslog just information from the drive itself that it is retrying, and after 5 times it gives up and tells via sense-register that reading/reallocation failed? In that case, the kernel can't do anything to prevent it.

So, what do the gurus say? Is it the drive itself retrying or should I literally eat the kernel-source to find that one line of code that says "try it again! try it again! try it again!"

In case it's the drive, I assume I should look deeper in terminal commands, maybe it's doable for some drives to turn retrying off. I'm also curious if it's even a normal retry, or if it's the reallocation itself.

In any case, turning reallocation off would be awesome, but as far as I know it can only be done through terminal commands, and up until now I've only done two .11 BSY-Fixes, so there's a lot to learn...

Thanks in advance,
Zuujin

[Zuujin]

I hate to double post, but is there really no one who can answer me this? I thought it's a simple question for Pros if drives are retrying on their own and telling that via their registers or not. I'm just looking for a push in the right direction, although more information is appreciated also

Zuujin

[BlackST]

You have to do your homework.

Anyway it is possible that "some sectors" are totally screwed so even if you could read raw data from them it would be garbled.
Other things are drive-specific and also fall into proprietary info.

If you are doing this kind of job to family and friends, live with it or be honest and ask them to fund you to get some more decent tools if they really want some more data, otherwise be 2x honest with your customers (*cough*) and keep outsourcing.

Final note : as usually people are liars when it comes at saying what exactly happened to the drive, i.e. it was dropped -shocked- dismantled- chewed by dog, horse, red fish etc. (in the vain hope they can save something) you can experience head crash after "some retry" on "bad" (oh look.. there was a nice ring on the platter.... ) so be careful or your gentle effort to help result in a pain in..............

[northwind]

it was dropped -shocked- dismantled- chewed by dog, horse, red fish etc.

[Vulcan]

@Zuujin,

I thought it's a simple question

Actually you asked several questions, but some are based on wrong assumptions / understandings so it would require a long correction of those misunderstandings, before even starting to try to explain each of your answers. Unfortunately that long teaching exceeds my time limit, especially since my answers would likely cause even more questions, so I didn't reply at all. That sometimes happens here - someone asks complex (or misunderstood) questions, and then is surprised when no-one replies.

For example:

[...] I took a closer look at the sense-register [...]

There is no "sense register" on a SATA drive. IMHO you need to learn more about (S)ATA registers, (e.g. perhaps starting with old versions of the ATA spec, which I think are an easier starting point, before moving on to the current version) and about the Linux libata architecture and what it is trying to achieve, to better understand what the Linux messages mean.

Some of the messages you are seeing are SCSI-type representation of ATA errors, so you need to learn about "SAT" - SCSI to ATA translation, as done by libata.

The short answer to some of your questions is that the retries you are seeing are not commanded by the drive, but the drive will also be doing internal (invisible) retries (as normal). Therefore your questions asking whether retries are being done by the kernel or the drive cannot be answered as a "simple question", because the answer includes "and", not "or".

Looking at other parts of the messages, I am concerned about the specific ddrescue command line being used, but that's a whole different discussion.

I use a different OS when I'm doing this (as part of my non-DR job), but IMHO your idea to remove OS retries is a good one, if you are limited to only using ddrescue etc. instead of using professional imaging equipment where the retries are already controlled. As BlackST explained, there are limitations to the "amateur" approach.

I hope my short comments help to point you in the right direction for some topics you can research to better answer your own questions, but perhaps you will just be angry that I have not written the book that is needed to answer in more detail. If my comments help, then good. If not, then just ignore this and wait for someone else to reply

[Zuujin]

I hope my short comments help to point you in the right direction

Your answer was exacly what I was hoping for, thank you a lot! Instead of saying to "do my homework", you told me what my homework actually is and where my thinking is wrong

Zuujin