Dmesg pieno di errori I / O, smart ok, quattro dischi interessati

Sto lavorando su un server remoto (Dell Poweredge) che era una nuova installazione. Ha quattro unità (2 TB) e 2 SSD (250 GB). Un SSD contiene il sistema operativo (RHEL7) e i quattro dischi meccanici alla fine conterranno un database Oracle.

Il tentativo di creare un array RAID software ha portato a dischi costantemente contrassegnati come difettosi. Il controllo di dmesg genera una serie di errori seguenti,

[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

Questi errori si verificano per tutti e quattro i dischi meccanici (sdc / sdd / sde / sdf) SMARTctl ha superato tutti e quattro i dischi, test lunghi e brevi. Attualmente sto eseguendo badblock (test della modalità di scrittura ~ 35 ore, probabilmente altri 35).

I seguenti sono gli errori che ho sospettato / considerato sulla ricerca

HDD fallito - Sembra improbabile che 4 dischi "ricondizionati" siano DOA, vero?
Problema del controller di archiviazione (cavo danneggiato?) - Sembra che influirebbe anche sull'SSD?
- Problema del kernel, l'unica modifica al kernel di serie è stata l'aggiunta di kmod-oracleasm. Davvero non vedo come causerebbe questi guasti, ASM non è impostato affatto.

Un altro evento degno di nota è stato il tentativo di azzerare i dischi (parte della risoluzione iniziale dei problemi), utilizzando il comando $ dd se = / dev / zero di = / dev / sdX ha prodotto questi errori,

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 qualcuno qui potesse condividere alcune idee su cosa potrebbe causare questo, sarei grato. Sono propenso a seguire il rasoio di Occam qui e andare dritto per gli HDD, l'unico dubbio deriva dall'improbabilità di quattro HDD falliti fuori dalla scatola.

Domani andrò al sito per un controllo fisico e riferirò la mia valutazione di questa macchina ai piani più alti. Se c'è qualcosa che dovrei ispezionare fisicamente (oltre a cavi / connessioni / alimentatore) per favore fatemelo sapere.

Grazie.

— Scu11y
fonte

Quando dici SMART "ok", intendi solo la salute generale? Esistono contatori grezzi individuali per settori riallocati o in sospeso diversi da zero? Le unità non si dichiarano immediatamente fallite nel primo settore danneggiato, anche se è illeggibile. Usa smartctl -x /dev/sdao qualcosa del genere. Ma è altamente sospetto che sia la stessa LBA su tutti i dischi.

— Peter Cordes,

I ddtest mostrano che i quattro dischi non funzionano tutti allo stesso indirizzo LBA . Poiché è estremamente improbabile che tutti e quattro i dischi si guastino nella stessa identica posizione, sospetto fortemente che ciò sia dovuto a problemi di controller o di cablaggio.

— shodanshok
fonte

È difficile dirlo senza ulteriori test. Ad ogni modo, la prima cosa che vorrei controllare / sostituire sono i cavi che collegano il controller al backplane.

— shodanshok,

I cavi ad alta velocità di trasmissione dati, come quelli SATA / SAS da 6/12 Gbs, non riguardano solo la continuità elettrica, ma soprattutto la chiarezza del segnale e il basso rumore. Prova a cancellare fisicamente i connettori e a riposizionare i cavi. Se l'errore persiste, prova a modificarli e, infine, prova un controller diverso.

— shodanshok,

Lo stesso LBA sembra improbabile che sia un problema di cablaggio. A meno che i dati in quel settore non siano solo una sequenza di bit nel peggiore dei casi per alcuni rimescolamenti (per prevenire corse estese di auto-clock che sconfigge tutto zero) o ECC sul collegamento SATA / SAS. Non sono sicuro di quale codifica utilizzi quel link. Il controller è plausibile però; lo stesso LBA su ciascuno dei dischi multipli richiede una sorta di spiegazione del fattore comune.

— Peter Cordes,

@ djsmiley2k È difficile che tutti e quattro finiscano ddnella cache sullo stesso indirizzo RAM non funzionante. Inoltre, la DRAM di PERC è protetta da ECC e, anche se la RAM ECC fallisce, è relativamente rara. Detto questo, il controller può essere la fonte dei problemi, quindi, se la sostituzione dei cavi non aiuta, l'OP dovrebbe provare a scambiare il controller.

— shodanshok,

Bene amici miei, avevate ragione. Cavi + controller scambiati e ora 600 GB in un processo di azzeramento dd e finora nessun errore. Sembra che tutto funzioni correttamente ora. Grazie ancora per tutte le conoscenze che hai condiviso. Sono sempre grato a questa community per la tua competenza e disponibilità a condividerla. :)

— Scu11y,