Dmesg cheio de erros de E / S, smart ok, quatro discos afetados

Estou trabalhando em um servidor remoto (Dell Poweredge) que foi uma nova instalação. Possui quatro unidades (2 TB) e 2 SSDs (250 GB). Um SSD contém o sistema operacional (RHEL7) e os quatro discos mecânicos acabarão por conter um banco de dados Oracle.

Tentar criar uma matriz RAID de software levou os discos a serem constantemente marcados como defeituosos. A verificação do dmesg gera vários dos seguintes erros,

[127491.711407] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719699] sd 0:0:4:0: [sde] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127491.719717] sd 0:0:4:0: [sde] Sense Key : Aborted Command [current]
[127491.719726] sd 0:0:4:0: [sde] Add. Sense: Logical block guard check failed
[127491.719734] sd 0:0:4:0: [sde] CDB: Read(32)
[127491.719742] sd 0:0:4:0: [sde] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127491.719750] sd 0:0:4:0: [sde] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127491.719757] blk_update_request: I/O error, dev sde, sector 3907026080
[127491.719764] Buffer I/O error on dev sde, logical block 488378260, async page read
[127497.440222] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.440240] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.440249] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.440258] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.440266] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.440273] sd 0:0:5:0: [sdf] CDB[10]: 00 01 a0 00 00 01 a0 00 00 00 00 00 00 00 00 08
[127497.440280] blk_update_request: I/O error, dev sdf, sector 106496
[127497.901432] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.901449] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.901458] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.901467] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.901475] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.901482] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.901489] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911003] sd 0:0:5:0: [sdf] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[127497.911019] sd 0:0:5:0: [sdf] Sense Key : Aborted Command [current]
[127497.911029] sd 0:0:5:0: [sdf] Add. Sense: Logical block guard check failed
[127497.911037] sd 0:0:5:0: [sdf] CDB: Read(32)
[127497.911045] sd 0:0:5:0: [sdf] CDB[00]: 7f 00 00 00 00 00 00 18 00 09 20 00 00 00 00 00
[127497.911052] sd 0:0:5:0: [sdf] CDB[10]: e8 e0 7c a0 e8 e0 7c a0 00 00 00 00 00 00 00 08
[127497.911059] blk_update_request: I/O error, dev sdf, sector 3907026080
[127497.911067] Buffer I/O error on dev sdf, logical block 488378260, async page read

Esses erros ocorrem em todos os quatro discos mecânicos (sdc / sdd / sde / sdf). O SMARTctl passou nos quatro discos, testes longos e curtos. Atualmente, estou executando badblocks (teste do modo de gravação ~ 35 horas, provavelmente mais 35 para ir).

A seguir estão os erros que eu suspeitei / considerei na pesquisa

HDD com falha - Parece improvável que 4 discos "recondicionados" sejam DOA, não é?
Problema no controlador de armazenamento (cabo defeituoso?) - Parece que também afetaria os SSDs?
- Problema no kernel, A única alteração no kernel padrão foi a adição do kmod-oracleasm. Realmente não vejo como isso causaria essas falhas, o ASM não está configurado.

Outro evento digno de nota foi ao tentar zerar os discos (parte da solução inicial de problemas), usando o comando $ dd se = / dev / zero de = / dev / sdX gerou esses erros,

dd: writing to ‘/dev/sdc’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70583 s, 32.0 MB/s
dd: writing to ‘/dev/sdd’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.70417 s, 32.0 MB/s
dd: writing to ‘/dev/sde’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71813 s, 31.7 MB/s
dd: writing to ‘/dev/sdf’: Input/output error
106497+0 records in
106496+0 records out
54525952 bytes (55 MB) copied, 1.71157 s, 31.9 MB/s

Se alguém aqui puder compartilhar algumas idéias sobre o que pode estar causando isso, eu ficaria agradecido. Estou inclinado a seguir a navalha do occam aqui e ir direto para os HDDs, a única dúvida decorre da improbabilidade de quatro HDDs fracassados prontos para uso.

Amanhã vou dirigir-me ao local para uma inspeção física e relatar minha avaliação desta máquina aos superiores. Se houver algo que eu deva inspecionar fisicamente (além de cabos / conexões / fonte de alimentação), entre em contato.

Obrigado.

— Scu11y
fonte

Quando você diz SMART "ok", você quer dizer apenas a saúde geral? Existem contadores brutos individuais para setores realocados ou pendentes diferentes de zero? As unidades não se declaram imediatamente fracassadas no primeiro setor ruim, mesmo que seja ilegível. Use smartctl -x /dev/sdaou algo assim. Mas é altamente suspeito que seja o mesmo LBA em todos os discos.

— Peter Cordes

Seus ddtestes mostram os quatro discos todos com falha no mesmo endereço LBA . Como é extremamente improvável que todos os quatro discos falhem exatamente no mesmo local, suspeito fortemente que isso ocorra devido a problemas de controlador ou de cabeamento.

— shodanshok
fonte

É difícil dizer sem mais testes. Enfim, o primeiro pensamento que eu controlaria / substituiria seria os cabos que conectam o controlador ao backplane.

— shodanshok

Os cabos com alta taxa de dados, como os SATA / SAS de 6/12 Gbs, não são apenas sobre continuidade elétrica, mas principalmente sobre clareza do sinal e baixo ruído. Tente limpar fisicamente os conectores e recolocar os cabos. Se o erro persistir, tente alterá-los e, finalmente, tente um controlador diferente.

— shodanshok

É improvável que o mesmo LBA seja um problema de cabeamento. A menos que os dados nesse setor sejam apenas uma sequência de bits do pior caso para alguns embaralhar (para impedir execuções prolongadas de auto-clock que derrotam com zero) ou ECC através do link SATA / SAS. Não tenho certeza de qual codificação esse link usa. O controlador é plausível; O mesmo LBA em cada um dos vários discos precisa de algum tipo de explicação sobre fatores comuns.

— Peter Cordes

@ djsmiley2k É difícil que todos os quatro ddterminem em cache no mesmo endereço de RAM com falha. Além disso, a DRAM da PERC é protegida por ECC e, embora a RAM do ECC também falhe, é relativamente incomum. Dito isso, o controlador pode ser a fonte dos problemas; portanto, se a troca de cabos não ajudar, o OP deve tentar trocar o controlador.

— shodanshok

Bem, meus amigos, você estava certo. Cabos + controladores trocados e agora 600 GB em um processo de zeragem de dd e nenhum erro até agora. Parece que tudo está funcionando corretamente agora. Agradecemos novamente por todo o conhecimento que você compartilhou. Sempre sou grato a esta comunidade por sua experiência e vontade de compartilhá-la. :)

— Scu11y