Trapping “READ FPDMA QUEUED”

Question

Recentemente, encontrei uma mensagem do kernel:

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

Consegui corrigir o erro e escrevi uma descrição detalhada do processo complicado usado para reparar o disco. Então ficou com preguiça de postar (acho que vou neste fim de semana).

O que eu gostaria de fazer agora é criar alguns programas para automatizar o processo. Para fazer isso eu preciso "capturar o erro do kernel".

Por armadilha, quero dizer: 1) Encerre a chamada do sistema que está causando o erro.    Percebo que, muitas vezes, erros como esse fazem com que o hd pare de funcionar, ou seja, ignoram os pedidos de outras chamadas de comando do sistema até que esse processo tenha terminado. Muitas vezes, fazendo com que as outras chamadas retornem erros. Com um programa de diagnóstico, isso fará com que a ação errada seja identificada como o culpado.

2) Envie um sinal de algum tipo para o processo de chamada para informar que é o culpado.

Sugestões?

    

Answer 1

O programa que o "causou" (na verdade, é causado por hardware ruim, seria mais apropriado dizer que "o programa que foi vítima dele") pode nem existir mais.

Por exemplo, envie uma gravação e saia. A gravação ficará nos buffers do kernel até que o kernel execute writeback. Nesse ponto, pode ocorrer um erro de E / S.

Quando o programa ainda existe, ele já será informado do erro. Por exemplo, read definirá errno para EIO . (Esse erro também pode voltar de write , fsync , fdatasync ou mesmo close .)

O motivo que leva para sempre não tem nada a ver com o kernel, é inteiramente a unidade. A unidade gasta um tempo tentando ler novamente para ver se consegue entender o setor corrompido. Se você não quer isto (por exemplo, porque você está rodando em RAID, e irá apenas reprogramar o setor para o espelho do disco) você pode tentar alterar as configurações do SCT Error Recovery Control usando smartctl. Tenha em atenção que muitos discos não empresariais não suportam isto.

Exceto no caso de RAID (ou similar), não há como corrigi-lo automaticamente. Os dados foram perdidos. O kernel não pode consertar isso.

Se você estiver executando o RAID de software do Linux (mdraid), mesmo com um kernel meio recente, o mdraid corrigirá automaticamente lendo o setor com erro do espelho e gravando o setor correto de volta na unidade com um erro de leitura .

Se você está fazendo isso em um write em vez de em read , substitua a unidade.

(BTW: READ FPDMA QUEUED não é um erro. É apenas o comando (S) ATA que falhou. "Erro Médio" é o erro.)