Dmesg lleno de errores de E / S, inteligente, cuatro discos afectados

Estoy trabajando en un servidor remoto (Dell Poweredge) que era una instalación nueva. Tiene cuatro unidades (2 TB) y 2 SSD (250 GB). Un SSD contiene el sistema operativo (RHEL7) y los cuatro discos mecánicos eventualmente contendrán una base de datos Oracle.

Intentar crear una matriz RAID de software provocó que los discos se marcaran constantemente como defectuosos. La comprobación de dmesg genera una serie de los siguientes errores,

[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

Estos errores ocurren para los cuatro discos mecánicos, (sdc / sdd / sde / sdf) SMARTctl pasó los cuatro discos, pruebas largas y cortas. Actualmente estoy ejecutando badblocks (prueba de modo de escritura ~ 35 horas en, probablemente otros 35 para ir).

Los siguientes son los errores que sospeché / consideré durante la investigación

HDD fallido: parece poco probable que 4 discos "restaurados" sean DOA, ¿no?
Problema con el controlador de almacenamiento (¿cable defectuoso?): ¿Parece que también afectaría a los SSD?
- Problema con el kernel. El único cambio en el kernel de stock fue la adición de kmod-oracleasm. Realmente no veo cómo causaría estas fallas, ASM no está configurado en absoluto.

Otro evento notable fue cuando intentaba poner a cero los discos (parte de la solución de problemas temprana), usando el comando $ dd if = / dev / zero of = / dev / sdX arrojó estos errores,

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

Si alguien aquí pudiera compartir alguna idea de lo que podría estar causando esto, estaría agradecido. Me inclino por seguir aquí la navaja de afeitar de occam e ir directamente a los discos duros, la única duda proviene de la improbabilidad de cuatro discos duros fallidos fuera de la caja.

Mañana conduciré al sitio para una inspección física y para informar mi evaluación de esta máquina a los superiores. Si hay algo que debería inspeccionar físicamente (más allá de los cables / conexiones / fuente de alimentación), hágamelo saber.

Gracias.

— Scu11y
fuente

Cuando dices SMART "ok", ¿te refieres a la salud general? ¿Hay contadores brutos individuales para sectores reasignados o pendientes que no sean cero? Las unidades no se declaran inmediatamente fallidas en el primer sector defectuoso, a pesar de que es ilegible. Uso smartctl -x /dev/sdao algo. Pero es muy sospechoso que sea el mismo LBA en todos los discos.

— Peter Cordes

Sus ddpruebas muestran que los cuatro discos fallan en la misma dirección LBA . Como es extremadamente improbable que cuatro discos fallen en la misma ubicación, sospecho que se debe a problemas con el controlador o el cableado.

— shodanshok
fuente

Es difícil saberlo sin más pruebas. De todos modos, lo primero que pensaría que controlaría / reemplazaría es los cables que conectan el controlador al plano posterior.

— shodanshok

Los cables de alta velocidad de datos, como los SATA / SAS de 6/12 Gbs, no solo tienen que ver con la continuidad eléctrica, sino principalmente con la claridad de la señal y el bajo nivel de ruido. Intente limpiar físicamente los conectores y vuelva a colocar los cables. Si el error persiste, intente cambiarlos y, finalmente, pruebe con un controlador diferente.

— shodanshok

Same-LBA parece poco probable que sea un problema de cableado. A menos que los datos en ese sector resulten ser una secuencia de bits en el peor de los casos para algún cifrado (para evitar ejecuciones extendidas de auto-reloj de derrota a cero) o ECC a través del enlace SATA / SAS. No estoy seguro de qué codificación usa ese enlace. Sin embargo, el controlador es plausible; El mismo LBA en cada uno de los discos múltiples necesita algún tipo de explicación de factor común.

— Peter Cordes

@ djsmiley2k Es difícil que los cuatro ddterminaron en caché en la misma dirección RAM que falla. Además, la DRAM de PERC está protegida por ECC y, aunque la RAM de ECC también falla, es relativamente poco común. Dicho esto, el controlador puede ser la fuente de los problemas, por lo que, si cambiar los cables no ayuda, el OP debe intentar cambiar el controlador.

— shodanshok

Bueno mis amigos, tenías razón. Cables + controladores intercambiados y ahora 600 GB en un proceso de puesta a cero dd y sin errores hasta el momento. Parece que todo está funcionando correctamente ahora. Gracias nuevamente por todo el conocimiento que ha compartido. Siempre estoy agradecido con esta comunidad por su experiencia y disposición para compartirla. :)

— Scu11y