Dmesg plein d'erreurs d'E / S, ok intelligent, quatre disques affectés

8

Je travaille sur un serveur distant (Dell Poweredge) qui était une nouvelle installation. Il dispose de quatre disques (2 To) et de 2 SSD (250 Go). Un SSD contient le système d'exploitation (RHEL7) et les quatre disques mécaniques vont finalement contenir une base de données Oracle.

Essayer de créer une matrice RAID logicielle a conduit à des disques constamment marqués comme défectueux. La vérification de dmesg génère une série des erreurs suivantes,

[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

Ces erreurs se produisent pour les quatre disques mécaniques, (sdc / sdd / sde / sdf) SMARTctl a réussi les quatre disques, tests longs et courts. J'exécute actuellement des badblocks (test du mode d'écriture ~ 35 heures, probablement encore 35 heures).

Voici les erreurs que j'ai soupçonnées / prises en compte lors de la recherche

  • Disque dur défectueux - Il semble peu probable que 4 disques «remis à neuf» soient DOA, n'est-ce pas?

  • Problème de contrôleur de stockage (mauvais câble?) - Il semble que cela affecterait également les SSD?

    • Problème de noyau, le seul changement au noyau de stock a été l'ajout de kmod-oracleasm. Je ne vois vraiment pas comment cela pourrait causer ces défauts, ASM n'est pas configuré du tout.

Un autre événement notable a été lors de la tentative de remise à zéro des disques (dans le cadre du dépannage précoce), en utilisant la commande $ dd si = / dev / zero of = / dev / sdX a généré ces erreurs, 

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 quelqu'un ici pouvait partager un aperçu de ce qui pourrait causer cela, je vous en serais reconnaissant. Je suis enclin à suivre le rasoir d'Occam ici et à aller directement vers les disques durs, le seul doute vient de l'improbabilité de quatre disques durs défectueux hors de leur boîte.

Je me rendrai sur le site demain pour une inspection physique et pour faire rapport de mon évaluation de cette machine aux plus hauts responsables. S'il y a quelque chose que je devrais inspecter physiquement (au-delà des câbles / connexions / alimentation), veuillez me le faire savoir.

Merci.

redhat hard-drive io Scu11y
la source
Lorsque vous dites SMART "ok", voulez-vous simplement dire la santé globale? Existe-t-il des compteurs bruts individuels pour les secteurs réaffectés ou en attente non différents de zéro? Les disques ne se déclarent pas immédiatement en panne sur le premier mauvais secteur, même s'il est illisible. Utilisez smartctl -x /dev/sdaou quelque chose. Mais il est très suspect que ce soit le même LBA sur tous les disques.
Peter Cordes

Réponses:

14

Vos ddtests montrent que les quatre disques échouent tous à la même adresse LBA . Comme il est extrêmement improbable que quatre disques tombent tous en panne au même endroit, je soupçonne fortement que cela est dû à des problèmes de contrôleur ou de câblage.

shodanshok
la source
1
C'est difficile à dire sans tests supplémentaires. Quoi qu'il en soit, la première chose que je voudrais contrôler / remplacer est les câbles reliant le contrôleur au fond de panier.
shodanshok
4
Les câbles à haut débit, comme ceux SATA / SAS 6/12 Gbs, ne concernent pas seulement la continuité électrique, mais surtout la clarté du signal et le faible bruit. Essayez de dégager physiquement les connecteurs et de réinstaller les câbles. Si l'erreur persiste, essayez de les changer et, enfin, essayez un autre contrôleur.
shodanshok
2
Same-LBA ne semble pas être un problème de câblage. À moins que les données de ce secteur ne se trouvent être une séquence de bits du pire des cas pour un brouillage (pour éviter des exécutions étendues de l'auto-synchronisation à zéro) ou ECC sur la liaison SATA / SAS. Je ne sais pas quel encodage ce lien utilise. Le contrôleur est plausible cependant; même LBA sur chacun des disques multiples a besoin d'une sorte d'explication de facteur commun.
Peter Cordes
3
@ djsmiley2k Il est difficile que les quatre ddextrémités soient mises en cache sur la même adresse RAM défaillante. De plus, la DRAM de PERC est protégée par ECC et, bien que la RAM ECC échoue également, elle est relativement rare. Cela dit, le contrôleur peut être à l'origine des problèmes.Par conséquent, si le changement de câbles n'aide pas, l'OP doit essayer d'échanger le contrôleur.
shodanshok
2
Eh bien mes amis, vous aviez raison. Câbles + contrôleurs échangés et maintenant 600 Go dans un processus de mise à zéro dd et aucune erreur jusqu'à présent. On dirait que tout fonctionne correctement maintenant. Merci encore pour toutes les connaissances que vous avez partagées. Je suis toujours reconnaissant à cette communauté pour son expertise et sa volonté de la partager. :)
Scu11y