SCSI Error sur un disque SAS d'un zpool en raidz2

Le
Francis Chartier
Bonjour

Soit un serveur sous freenas 9.10, dont un disque (/dev/da1 faisant
partie d'un zpool de 6 disques SAS en raidz2) a généré une e=
rreur
apparaissant dans un fragment de log reçu par mail :

> (da1:mps0:0:1:0): READ(10). CDB: 28 00 1a e0 fe 6a 00 00 33 00
> (da1:mps0:0:1:0): CAM status: SCSI Status Error
> (da1:mps0:0:1:0): SCSI status: Check Condition
> (da1:mps0:0:1:0): SCSI sense: MEDIUM ERROR asc:16,0 (Data
> synchronization mark error) (da1:mps0:0:1:0): Info: 0x1ae0fe6a
> (da1:mps0:0:1:0): Field Replaceable Unit: 128
> (da1:mps0:0:1:0): Command Specific Info: 0x86011200
> (da1:mps0:0:1:0): Actual Retry Count: 255
> (da1:mps0:0:1:0): Descriptor 0x80: 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 (da1:mps0:0:1:0): Retrying command (per sense data)

C'est pour l'instant le seul morceau de log dont je dispose, tant que
je ne me serai pas rendu sur place afin de pouvoir diagnostiquer plus
précisément.

A priori il s'agit de la première erreur de ce type rencontrée de=
puis
la mise en service du matériel il y a à peu près 10 mois,
fonctionnement 24x7 sans soucis.
Les disques sont pilotés par le controleur SAS LSI2308
embarqué sur une carte mère SUPERMICRO X10SL7-F, avec firmware mi=
s à
jour.

D'après ce que j'ai lu sur les "SCSI sense keys" il s'agit a priori
d'une erreur de support qui pourrait être corrigée par une r=
-allocation
du ou des blocs concernés.

D'après votre expérience quel est le degré d'urgence : c'est=
à
considérer habituellement comme signe avant coureur de la mort à =
court
ou moyen terme du disque (donc envisager le remplacement rapide), ou
simple incident de parcours à corriger et à surveiller.
Je sais qu'étant en raidz2 je n'ai entamé que la ceinture et pas =
les
bretelles, mébon : shit happens. :)

De toute façon je vais aller sur place pour vérifier, mais je n'a=
i pas
rencontré assez d'incidents de ce genre pour me faire une idée su=
r la
gravité et l'urgence de la situation, en général on m'appell=
e quand le
disque est mort et le serveur aux abonnés absents. :)

--
Francis Chartier
Bisounours Asocial #0
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Belhomme
Le #26437171
Le Thu, 29 Jun 2017 14:27:43 +0200, Francis Chartier a écrit :
D'après ce que j'ai lu sur les "SCSI sense keys" il s'agit a priori
d'une erreur de support qui pourrait être corrigée par une ré-allocation
du ou des blocs concernés.

Il y a une erreur d'écriture sur un bloc du disque. Le disque doit être
remplacé.
Je ne connais pas bien ZFS, mais un RAID6 "traditionnel" équivalent à un
raidz2 aurait déjà écarté le disque et marqué le volume en "degraded"
--
Rico
Francis Chartier
Le #26437211
Le 02 Jul 2017 16:32:34 GMT,
Eric Belhomme
Le Thu, 29 Jun 2017 14:27:43 +0200, Francis Chartier a écrit :
D'après ce que j'ai lu sur les "SCSI sense keys" il s'agit a priori
d'une erreur de support qui pourrait être corrigée par une
ré-allocation du ou des blocs concernés.

Il y a une erreur d'écriture sur un bloc du disque. Le disque doit
être remplacé.

Ah.
Bon, je confirme rai ça demain matin en étant sur place, mais c'e st pas
vraiment une bonne nouvelle, même si c'est couvert par la garantie.
Je ne connais pas bien ZFS, mais un RAID6 "traditionnel" équivalent à
un raidz2 aurait déjà écarté le disque et marqué le volume en
"degraded"

De ce que j'ai lu, le problème est le temps nécessaire pour
la reconstruction d'un volume de plus de 15 TB en raid6

--
Francis Chartier
Bisounours Asocial #0
Eric Belhomme
Le #26437219
Le Mon, 03 Jul 2017 06:37:05 +0200, Francis Chartier a écrit :
De ce que j'ai lu, le problème est le temps nécessaire pour la
reconstruction d'un volume de plus de 15 TB en raid6

d'où l'importance de disposer de disques en "hot spare" sur une grappe
raid.
Perso je préfère limiter la densité de mes grappes, quitte à dédoubler
les grappes et les aggréger par la suite. C'est une des raisons qui me
font préférer Linux + LVM à Solaris|freeBSD + ZFS
--
Rico
Eric Masson
Le #26437224
Eric Belhomme 'Lut Éric,
d'où l'importance de disposer de disques en "hot spare" sur une grappe
raid.
Perso je préfère limiter la densité de mes grappes, quitte à dédoubler
les grappes et les aggréger par la suite. C'est une des raisons qui me
font préférer Linux + LVM à Solaris|freeBSD + ZFS

Je ne capte pas bien, tu peux ajouter à un zpool existant des vdevs de la
même topologie que le vdev initial et aussi des disques en hotspare.
J'ai raté quelque chose dans le besoin ?
Éric
--
je pense pas que ce soit toi....tu es bien trop vicieux pour agir de
cette façon. Toi ton genre, c'est plus de contacter banque direct en
esperant que je n'auras pas mes cadeaux de parrainages!!!!!
-+- JD in
Francis Chartier
Le #26437253
Le 03 Jul 2017 06:38:16 GMT, Eric Belhomme écrivait :
d'où l'importance de disposer de disques en "hot spare" sur une
grappe raid.

Certes, dans un monde parfit où le budget ne serait pas un problè me
pour le client. :)
--
Francis Chartier
Bisounours Asocial #0
Marc SCHAEFER
Le #26437254
Eric Belhomme
Il y a une erreur d'écriture sur un bloc du disque. Le disque doit être
remplacé.

Ca a plutôt l'air d'une erreur en lecture: quelque chose de plus grave
qu'un bloc avec 1-2 erreurs corrigeables, mais carrément une limite de
bloc ou de piste illisible. Il faudrait le manuel du disque-dur
spécifique (sisi, ça se faisait dans les années 90), ou sinon voir
plus bas[1].
Cela signifie qu'après une écriture il y a longtemps, les données
sont maintenant illisibles sur ce disque-dur.
Je ne connais pas bien ZFS, mais un RAID6 "traditionnel" équivalent à un
raidz2 aurait déjà écarté le disque et marqué le volume en "degraded"

Non, il y a d'autres techniques: simplement rediriger la lecture de CE
block sur un autre membre de l'array (RAID1), ou reconstruire le bloc.
Il n'est pas nécessaire de marquer le disque entier comme mauvais pour
1 ou 2 bad blocks. Cela permet alors de survivre à des erreurs
multiples tant qu'elles ne concernent pas le même bloc.
Toutefois, ici, vu le type de l'erreur, je recommande un contrôle des
conditions environnementales (18 <= température <= 42), vibratoires et
de préparer une reconstruction de l'array sur un nouveau disque.
Sachant qu'il n'est pas rare qu'un rebuild, si les conditions
sont mauvaises, provoque d'autres erreurs sur d'autres risques.
[1] Standard SCSI-2 (ok, le 3 est plus actuel, mais je ne l'ai pas
en version informatique)
grep -i 'Data synchro' *
s2r10h07.txt:| 16h 00h D W O DATA SYNCHRONIZATION MARK ERROR |
s2r10h08.txt: be included (e.g., data synchronization mark within the area covered by
s2r10h08.txt: be included (e.g., a data synchronization mark within the area covered
s2r10ha.txt:| 16 00 DW O DATA SYNCHRONIZATION MARK ERROR |
Eric Belhomme
Le #26437297
Le Mon, 03 Jul 2017 15:32:29 +0200, Francis Chartier a écrit :
d'où l'importance de disposer de disques en "hot spare" sur une grappe
raid.

Certes, dans un monde parfit où le budget ne serait pas un problème pour
le client. :)

Sur un RAID en prod, un disque en hot-spare est *mandatory*. Ne laisse
pas le choix à ton client !
Et 2 ou 3 disques en spare sur une étagère sont plus que recommandés...
--
Rico
Nicolas George
Le #26437306
Eric Belhomme , dans le message
Sur un RAID en prod, un disque en hot-spare est *mandatory*. Ne laisse
pas le choix à ton client !

Et quand on parle marketeux à un client, le franglais aussi, il est
« mandatory », et le mot « obligatoire » il est #verbotten# ?
Francis Chartier
Le #26437316
Le Mon, 3 Jul 2017 17:20:42 +0200, Francis Chartier
Bon, prochaine étape demain : test via smartd et j'aviserai en
fonction des résultats

Bon, résultat des courses, a priori ce disque est en train de
défaillir.
=== START OF INFORMATION SECTION ===
Vendor: SEAGATE
Product: ST4000NM0023
Revision: 0004
Compliance: SPC-4
User Capacity: 4,000,787,030,016 bytes [4.00 TB]
Logical block size: 512 bytes
LU is fully provisioned
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Logical Unit id: 0x5000c50096d52103
Serial number: S1Z20JR80000K63119L1
Device type: disk
Transport protocol: SAS (SPL-3)
Local Time is: Tue Jul 4 08:21:30 2017 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature: 43 C
Drive Trip Temperature: 60 C
Manufactured in week 14 of year 2016
Specified cycle count over device lifetime: 10000
Accumulated start-stop cycles: 129
Specified load-unload count over device lifetime: 300000
Accumulated load-unload cycles: 441
Elements in grown defect list: 71
Vendor (Seagate) cache information
Blocks sent to initiator = 1260434722
Blocks received from initiator = 1815320906
Blocks read from cache and sent to initiator = 118564603
Number of read and write commands whose size <= segment size = 1387 7360
Number of read and write commands whose size > segment size = 697
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 7519.17
number of minutes until next internal SMART test = 49
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 byte s] errors
read: 1471795615 12 0 1471795627 13 645.3 43 1
write: 0 0 0 0 0 5156.655 0
Non-medium error count: 516


La liste des erreurs montre qu'elles sont de plus en plus fréquentes
depuis une petite douzaine de jours, avec une majorité d'erreurs de
type 1 (soft errors) corrigées par ré-écriture au même endroit.
1 seule erreur non corrigée mais déjà 71 "Elements in grown defect
list"
Les autres disques sont loin de présenter un tel nombre d'erreurs,
entre 0 et 20, 1 seul présente un "Elements in grown defect
list".
Les autres présentent un nombre d'erreurs très bas (entre 0 et 20 ) et un seul
présente un Elements in grown defect list à 1, les autres sont to us à 0.
Bon, c'est parti pour un remplacement
--
Francis Chartier
Bisounours Asocial #0
Eric Belhomme
Le #26437328
Le Tue, 04 Jul 2017 08:33:01 +0000, Nicolas George a écrit :
Et quand on parle marketeux à un client, le franglais aussi, il est
« mandatory », et le mot « obligatoire » il est #verbotten# ?

Que celui qui n'est s'est jamais retrouvé avec un RAID cassé suite à la
défaillance en cascade de disques sur une grappe sans "hot-spare" (veux-
tu que je te traduise celui-ci aussi ?) me jette le premier disque dur...
--
Rico
et accessoirement, je ne donne pas dans le marketing
Publicité
Poster une réponse
Anonyme