1

Waiting too long when encountering an unreadable sector on a disk is really very annoying. (Especially if you are trying to read as much data as can be read from a disk with bad sectors, and do it quickly, for backup and restoration.)

The disk reports read errors (sense errors).

Can the disk (ATA) be setup so that a failing read doesn't take too long, so that it can be dropped, and the reading process and the disk wouldn't be blocked, and the next read could be attempted?

Or perhaps the linux disk driver can be set up to achieve this?

Or the reading process in linux can do something to avoid long reading?

Improve this question
1

2 Answers 2

Reset to default
2

Can the disk (ATA) be setup so that a failing read doesn't take too long, so that it can be dropped, and the reading process and the disk wouldn't be blocked, and the next read could be attempted?

No.

My understanding of this is that it's a logical problem resulting from a design choice (not unique to linux) that favours performance and stability for working hardware, since the OS cannot reasonably be expected to deal with the endless possibilities presented by "possibly malfunctioning" hardware. We do have a Q&A about this.

if you are trying to read as much data as can be read from a disk with bad sectors

If it's bad sectors, you are in luck; umount the affected partitions and (presuming they are ext formatted) run e2fsck -cy /dev/whatever on them. The -c switch runs badblocks and adds individual addresses to a "bad blocks list" in the partition; when it is subsequently mounted, the system will never attempt to access them. This may mean you've lost some data; bits of it may be found in the /lost+found directory. The -y switch saves you from manually saying "Yes, fix it" to fsck's questions, of which there may be a great many.

However, if it's not bad blocks (e.g., it's a failing controller), you are out of luck. Stuff breaks, which is why keeping regular backups of vital data is so important. I'm not sure if running e2fsck -cy on a disk with a broken controller may make the situation worse, which is something to consider, but OTOH, if you cannot get what you need anyway, you have nothing to lose.

Improve this answer
2
  • Wouldn't a SMART test be a faster and better solution than badblocks since it's more low-level and wouldn't cause the awful delays on bad sectors? I've been wondering quite a while why don't the tools like e2fsck have an option to incorporate the info from SMART... In my case, the traditional badblocks would also run into reading the bad sectors with huge delays, and take enormous time to complete, I'm afraid. (Once I could solve a similar problem without the hanging on IO, but I had to manually translate and copy bad sector addresses into commands from the output of smartctl. Few of them.
    – imz -- Ivan Zakharyaschev
    Jul 29, 2014 at 22:21
  • Yeah, the fsck badblocks scan does trigger the problem and can take a very long time (hours), but it will work on anything, and is pretty unequivocal if the issue is bad blocks. I've never used a SMART oriented utility for something like this and don't know the relative pros and cons -- but if there isn't an obvious way, "How can I get [whatever SMART tool] to add to an ext partition bad blocks list?" is a good question.
    – goldilocks
    Jul 30, 2014 at 0:17
1

Most Unix systems didn't implement asynchronous reads of local disks; attempting the call results in synchronous reads. In particular, in Linux the sleep for local disks is uninterruptible (which is annoying on scratched CDs).

If local disk IO happens to be interruptible on your platform you can use alarm(); read(); to set the maximum time you are willing to wait.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .