+-
最近我遇到了一条内核消息:
ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata3.00: irq_stat 0x40000008
ata3.00: failed command: READ FPDMA QUEUED
ata3.00: cmd 60/08:00:98:b2:78/00:00:13:00:00/40 tag 0 ncq 4096 in
res 41/40:08:9a:b2:78/00:00:13:00:00/00 Emask 0x409 (media error) <F>
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
ata3.00: configured for UDMA/133
sd 2:0:0:0: [sda] Unhandled sense code
sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
13 78 b2 9a
sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
sd 2:0:0:0: [sda] CDB: Read(10): 28 00 13 78 b2 98 00 00 08 00
end_request: I/O error, dev sda, sector 326677146
ata3: EH complete
我设法纠正了错误并写了我用来修复磁盘的复杂过程的详细描述.然后懒得贴出来(猜猜我会在这个周末).
我现在想做的是创建一些程序来自动化这个过程.
为此,我需要“捕获内核错误”.
通过陷阱我的意思是:
1)终止导致错误的系统调用.
我注意到,像这样的错误通常会导致hd挂起,即忽略来自其他系统命令调用的请求,直到此进程运行完毕.通常会导致其他调用返回错误.使用诊断程序,这将导致错误的行为被确定为罪魁祸首.
2)向调用进程发送某种信号,让它知道它是罪魁祸首.
建议?
最佳答案
“引起”它的程序(实际上,它是由坏硬件引起的,更适合说“作为它的受害者的程序”)可能甚至不再存在.
例如,发送一个写,然后退出.写入将位于内核缓冲区中,直到内核执行回写.此时可能发生I / O错误.
当程序仍然存在时,它已经被告知错误.例如,read将errno设置为EIO. (此错误也可能来自write,fsync,fdatasync甚至关闭.)
它永远需要的原因与内核无关,它完全是驱动器.驱动器花了一段时间重试读取,看看它是否能够理解损坏的扇区.如果您不想这样(例如,因为您在RAID上运行,并且只是将扇区重新安排到磁盘的镜像),您可以尝试使用smartctl更改SCT错误恢复控制设置.请注意,许多非企业磁盘不支持此功能.
除了RAID(或类似)的情况,没有办法自动修复它.数据已丢失.内核无法解决这个问题.
如果您正在运行Linux软件RAID(mdraid),即使是最近一半的内核,mdraid也会通过从镜像中读取错误扇区来自动修复它,然后将读取错误写回正确的扇区.
如果您是在写入而不是读取时,请更换驱动器.
(顺便说一下:READ FPDMA QUEUED不是错误.它只是(S)ATA命令失败.“中等错误”是错误.)
点击查看更多相关文章
转载注明原文:linux – 陷阱“READ FPDMA QUEUED” - 乐贴网