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=C3=A9n=C3=A9r=C3=A9 une e=
rreur
apparaissant dans un fragment de log re=C3=A7u par mail :
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=C3=A9cis=C3=A9ment.
A priori il s'agit de la premi=C3=A8re erreur de ce type rencontr=C3=A9e de=
puis
la mise en service du mat=C3=A9riel il y a =C3=A0 peu pr=C3=A8s 10 mois,
fonctionnement 24x7 sans soucis.
Les disques sont pilot=C3=A9s par le controleur SAS LSI2308
embarqu=C3=A9 sur une carte m=C3=A8re SUPERMICRO X10SL7-F, avec firmware mi=
s =C3=A0
jour.
D'apr=C3=A8s ce que j'ai lu sur les "SCSI sense keys" il s'agit a priori
d'une erreur de support qui pourrait =C3=AAtre corrig=C3=A9e par une r=C3=
=A9-allocation
du ou des blocs concern=C3=A9s.
D'apr=C3=A8s votre exp=C3=A9rience quel est le degr=C3=A9 d'urgence : c'est=
=C3=A0
consid=C3=A9rer habituellement comme signe avant coureur de la mort =C3=A0 =
court
ou moyen terme du disque (donc envisager le remplacement rapide), ou
simple incident de parcours =C3=A0 corriger et =C3=A0 surveiller.
Je sais qu'=C3=A9tant en raidz2 je n'ai entam=C3=A9 que la ceinture et pas =
les
bretelles, m=C3=A9bon : shit happens. :)
De toute fa=C3=A7on je vais aller sur place pour v=C3=A9rifier, mais je n'a=
i pas
rencontr=C3=A9 assez d'incidents de ce genre pour me faire une id=C3=A9e su=
r la
gravit=C3=A9 et l'urgence de la situation, en g=C3=A9n=C3=A9ral on m'appell=
e quand le
disque est mort et le serveur aux abonn=C3=A9s absents. :)
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
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"
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 02 Jul 2017 16:32:34 GMT, Eric Belhomme <rico-{nospam}@ricozome.net> a écrit :
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
Le 02 Jul 2017 16:32:34 GMT,
Eric Belhomme <rico-{nospam}@ricozome.net> a écrit :
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
Le 02 Jul 2017 16:32:34 GMT, Eric Belhomme <rico-{nospam}@ricozome.net> a écrit :
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 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
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
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
Eric Belhomme <rico-{nospam}@ricozome.net> writes: '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 <http://www.le-gnu.net> : Petit neuneu Noël -+-
Eric Belhomme <rico-{nospam}@ricozome.net> writes:
'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 <http://www.le-gnu.net> : Petit neuneu Noël -+-
Eric Belhomme <rico-{nospam}@ricozome.net> writes: '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 <http://www.le-gnu.net> : Petit neuneu Noël -+-
Francis Chartier
Le 03 Jul 2017 06:38:16 GMT, Eric Belhomme <rico-{nospam}@ricozome.net> é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
Le 03 Jul 2017 06:38:16 GMT, Eric Belhomme <rico-{nospam}@ricozome.net>
é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. :)
Le 03 Jul 2017 06:38:16 GMT, Eric Belhomme <rico-{nospam}@ricozome.net> é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
Eric Belhomme <rico-{nospam}@ricozome.net> wrote:
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 <rico-{nospam}@ricozome.net> wrote:
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 |
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 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
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...
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
Eric Belhomme , dans le message <595b349b$0$31630$, a écrit :
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# ?
Eric Belhomme , dans le message
<595b349b$0$31630$426a74cc@news.free.fr>, a écrit :
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# ?
Eric Belhomme , dans le message <595b349b$0$31630$, a écrit :
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 Mon, 3 Jul 2017 17:20:42 +0200, Francis Chartier écrivait :
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
Le Mon, 3 Jul 2017 17:20:42 +0200, Francis Chartier
<num.0@bisounours-asocial.club> écrivait :
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
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.
Le Mon, 3 Jul 2017 17:20:42 +0200, Francis Chartier écrivait :
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 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
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
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
