Je ne vais pas commencer à raconter tout le temps que j'ai perdu
cet été avec mes ordinateurs : entre mon père qui a décidé de
déménager plein de choses dans son sous-sol et qui a branché
l'alimentation du disque dur externe de la machine servant de routeur
sur un transformateur délivrant la mauvaise tension, et un ordinateur
hébergé à l'ENS qui a été déconnecté sans aucun
avertissement et qui m'a valu quantité de mails pour expliquer la
situation aux utilisateurs, rien que raconter les choses prendrait
plus de temps que je n'en ai.
La dernière péripétie est que deux des trois disques durs
du PC que j'ai chez mes parents (et qui me sert notamment
de stockage de sauvegardes) ont décidé de mourir simultanément, et,
qui plus est, pendant que j'étais en vacances en Allemagne. L'un (un
Maxtor DiamondMax® STM3750330AS
de 750Go, acheté en
avril 2008 et utilisé seulement depuis novembre 2011,
nommé sdc
ou ata2.01
dans les logs qui
suivent) a brutalement cessé purement et simplement de répondre à la
moindre commande :
Sep 1 22:37:43 pleiades kernel: [1749716.736036] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep 1 22:37:43 pleiades kernel: [1749716.736044] ata2.01: failed command: SMART
Sep 1 22:37:43 pleiades kernel: [1749716.736050] ata2.01: cmd b0/da:00:00:4f:c2/00:00:00:00:00/10 tag 0
Sep 1 22:37:43 pleiades kernel: [1749716.736050] res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Sep 1 22:37:43 pleiades kernel: [1749716.736054] ata2.01: status: { DRDY }
Sep 1 22:37:48 pleiades kernel: [1749721.785014] ata2: link is slow to respond, please be patient (ready=0)
Sep 1 22:39:47 pleiades kernel: [1749724.182021] ata2: soft resetting link
Sep 1 22:39:47 pleiades kernel: [1749731.416141] ata2.01: qc timeout (cmd 0xec)
Sep 1 22:39:47 pleiades kernel: [1749731.416149] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 1 22:39:47 pleiades kernel: [1749731.416153] ata2.01: revalidation failed (errno=-5)
Sep 1 22:39:47 pleiades kernel: [1749736.312020] ata2: soft resetting link
Sep 1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, not capable of SMART self-check
Sep 1 22:39:47 pleiades kernel: [1749736.482563] ata2.01: configured for UDMA/133
Sep 1 22:39:47 pleiades kernel: [1749736.482584] ata2: EH complete
Sep 1 22:39:47 pleiades kernel: [1749746.720034] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Sep 1 22:39:47 pleiades kernel: [1749746.720043] ata2.01: failed command: SMART
Sep 1 22:39:47 pleiades kernel: [1749746.720050] ata2.01: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/10 tag 0 pio 512 in
Sep 1 22:39:47 pleiades kernel: [1749746.720050] res 40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Sep 1 22:39:47 pleiades kernel: [1749746.720054] ata2.01: status: { DRDY }
Sep 1 22:39:47 pleiades kernel: [1749751.769022] ata2: link is slow to respond, please be patient (ready=0)
Sep 1 22:39:47 pleiades kernel: [1749756.767014] ata2: device not ready (errno=-16), forcing hardreset
Sep 1 22:39:47 pleiades kernel: [1749756.767023] ata2: soft resetting link
Sep 1 22:39:47 pleiades kernel: [1749764.011135] ata2.01: qc timeout (cmd 0xec)
Sep 1 22:39:47 pleiades kernel: [1749764.011140] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 1 22:39:47 pleiades kernel: [1749764.011144] ata2.01: revalidation failed (errno=-5)
Sep 1 22:39:47 pleiades kernel: [1749769.060013] ata2: link is slow to respond, please be patient (ready=0)
Sep 1 22:39:47 pleiades kernel: [1749774.058012] ata2: device not ready (errno=-16), forcing hardreset
Sep 1 22:39:47 pleiades kernel: [1749774.058019] ata2: soft resetting link
Sep 1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, failed to read SMART Attribute Data
Sep 1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, Read SMART Self Test Log Failed
Sep 1 22:39:47 pleiades kernel: [1749786.302021] ata2.01: qc timeout (cmd 0xec)
Sep 1 22:39:47 pleiades kernel: [1749786.302026] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 1 22:39:47 pleiades kernel: [1749786.302029] ata2.01: revalidation failed (errno=-5)
Sep 1 22:39:47 pleiades kernel: [1749791.351016] ata2: link is slow to respond, please be patient (ready=0)
Sep 1 22:39:47 pleiades kernel: [1749796.349013] ata2: device not ready (errno=-16), forcing hardreset
Sep 1 22:39:47 pleiades kernel: [1749796.349024] ata2: soft resetting link
Sep 1 22:39:47 pleiades kernel: [1749828.593026] ata2.01: qc timeout (cmd 0xec)
Sep 1 22:39:47 pleiades smartd[5643]: Device: /dev/sdc, Read Summary SMART Error Log failed
Sep 1 22:39:47 pleiades kernel: [1749828.593035] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4)
Sep 1 22:39:47 pleiades kernel: [1749828.593039] ata2.01: revalidation failed (errno=-5)
Sep 1 22:39:47 pleiades kernel: [1749828.593042] ata2.01: disabled
Sep 1 22:39:47 pleiades kernel: [1749833.642016] ata2: link is slow to respond, please be patient (ready=0)
Sep 1 22:39:47 pleiades kernel: [1749838.640016] ata2: device not ready (errno=-16), forcing hardreset
Sep 1 22:39:47 pleiades kernel: [1749838.640028] ata2: soft resetting link
Sep 1 22:39:47 pleiades kernel: [1749840.841810] ata2: EH complete
Sep 1 22:39:47 pleiades kernel: [1749840.842031] end_request: I/O error, dev sdc, sector 15438448
Sep 1 22:39:47 pleiades kernel: [1749840.842036] md: super_written gets error=-5, uptodate=0
Sep 1 22:39:47 pleiades kernel: [1749840.842041] md/raid1:md2: Disk failure on sdc5, disabling device.
Sep 1 22:39:47 pleiades kernel: [1749840.842041] md/raid1:md2: Operation continuing on 2 devices.
Sep 1 22:39:47 pleiades kernel: [1749840.842206] sd 1:0:1:0: [sdc] Asking for cache data failed
Sep 1 22:39:47 pleiades kernel: [1749840.842213] sd 1:0:1:0: [sdc] Assuming drive cache: write through
— tandis que l'autre (un Western Digital Caviar
Blue® WD10EALX-009BA0
de 1To, acheté en juin 2012, et
nommé sdb
ou ata1.01
dans les logs qui
suivent) n'a pas tardé à se découvrir quantité de secteurs
défectueux :
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, FAILED SMART self-check. BACK UP DATA NOW!
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Prefailure Attribute: 3 Spin_Up_Time changed from 176 to 187
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, Failed SMART usage Attribute: 5 Reallocated_Sector_Ct.
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 200 to 42
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 7 Seek_Error_Rate changed from 200 to 21
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 107 to 108
Sep 2 22:55:54 pleiades smartd[9342]: Device: /dev/sdb, SMART Usage Attribute: 196 Reallocated_Event_Count changed from 200 to 84
(Qu'on se rassure, malgré le message trompeur, il n'était pas
vraiment à 108°C : le 108 est une valeur
normalisée SMART, qui pour ce fabricant semble
correspondre à environ 40°C.) Ce disque a continué à plus ou moins
fonctionner (mais lentement, en faisant des bruits bizarres, et de
rares vraies erreurs), au moins le temps de me permettre d'en
récupérer en catastrophe celles de mes données qui
n'étaient protégées que contre
l'échec d'un seul disque.
Je ne peux pas vraiment dire que je sois passé près de la
catastrophe : en vérité, non seulement comme je viens de le dire le
disque mourant a tenu le coup le temps que j'en extraie tout ce que je
voulais extraire, mais de toute façon les données vraiment importantes
étaient en redondance triple (RAID1 sur les trois
disques), et même ces données étaient essentiellement des sauvegardes
incrémentales de données qui sont en redondance au moins quintuple sur
des ordinateurs à deux endroits physiquement séparés (sans compter des
sauvegardes sur médias optiques) — bref, je suis passablement parano
avec la perte d'information. Néanmoins, j'aurais pu perdre quelques
choses qui m'auraient agacé, et beaucoup plus de temps que je n'en ai
déjà passé à racheter des nouveaux disques et recopier tout ce que
j'avais sur ceux-ci (ce qui, quand le disque dur mourant descend
jusqu'à 3Mo/s et qu'on a 750Go à copier, prend… longtemps). J'ai donc
augmenté ma paranoïa d'encore un cran et mis encore plus de partitions
en redondance triple : après tout, ça ne sert à rien d'économiser
vingt gigas par-ci par-là quand j'en ai des centaines dont je ne me
sers pas vraiment.
Mais au-delà de cette non-catastrophe, la question demeure de
savoir comment il se fait que deux disques durs aient pu mourir en
même temps (et cette question a de l'importance, parce que si deux
peuvent, alors trois peuvent aussi, et je ne serais
vraiment vraiment pas content). J'avais déjà eu
une expérience de ce genre qui
s'était avérée n'être qu'une vapeur du contrôleur, mais cette fois les
disques ont bien l'air d'être endomagés. Il n'y a pas eu d'orage à
cette période qui expliquerait, par exemple, une surtension
électrique. Je peux vaguement soupçonner soit une insuffisance de
l'alimentation ou une chaleur excessive, mais aucune de ces hypothèses
n'est corroborée par un indice tangible. Par ailleurs, les deux
disques ont commencé à défaillir à presque exactement 24h
d'intervalle, ce qui est peut-être significatif, mais je ne sais pas
de quoi (il n'est rien censé se passer de particulier à ce
moment-là).
J'ai racheté (à Hambourg) trois nouveaux disques durs, en essayant
de trouver trois constructeurs différents, mais comme je le
soupçonnais c'est une tâche impossible : je ne sais pas exactement
combien existent de chaînes vraiment indépendantes de fabrication de
disques durs, mais le nombre de marques semble être tombé à 2 (Seagate
ayant, je crois, acquis Maxtor ; et Western Digital), comme par hasard
ceux qui m'ont empiriquement posé le plus de problèmes par le passé
(alors que Hitachi, Samsung et IBM, qui semblaient
considérablement plus fiables, soient ne fabriquent plus de disques,
soit au moins ont cessé de les revendre aux péquenots comme moi).
Je constate aussi de nouveau ce que j'avais déjà cru détecter, à
savoir que (dans des mesures raisonnables) plus un disque dur est
ancien, plus il est fiable : ce sont mes disques les
plus récents qui ont lâché (pour référence, celui qui
continuait à fonctionner était un Samsung
SpinPoint® HD501LJ
de 500Go, acheté en novembre 2007).
Autrement dit, il me semble que sur un disque dur, le phénomène
d'usure avec le temps est beaucoup moins important que le
phénomène de défaut caché à la fabrication (appelé
aussi mortalité infantile
des disques durs) et que l'expérience
permet de dévoiler : plus votre disque a tenu longtemps, plus il y a
des chances qu'il soit de bonne qualité et continue à tenir longtemps.
Il est vrai que les deux disques dont on parle étaient tous trop vieux
pour vraiment entrer dans la case « mortalité infantile », donc c'est
peut-être simplement une coïncidence.
Bien sûr, mes observations aussi bien sur la fiabilité relative des
marques que sur la fiabilité avec le temps sont basées sur des données
statistiquement insuffisantes, et même pas collectées de façon
systématique. Ceux qui pourraient le mieux fournir des informations
vraiment scientifiques sur la fiabilité des disques, c'est Google :
malheureusement, une
étude qu'ils ont publiée il y a quelque temps à ce sujet ne veut
rien révéler sur les marques de disques durs plus ou moins fiables. À
défaut, j'ai trouvé deux rapports de la compagnie de stockage
Blackblaze, celle-ci
sur la durée de vie des disques durs en général
et celle-là
sur les marques plus ou moins fiables, qui corroborent au moins
partiellement mes impressions (les disques durs jeunes ont le plus
tendance à mourir, le minimum du taux de mortalité se situant d'après
eux vers 2 ans d'âge ; et Hitachi semble bien la marque la plus fiable
— ou du moins semblait). Il faut néanmoins bien prendre note que les
conditions d'utilisation (température, pourcentage du temps passé
allumé, nombre de cycles de garage des têtes, etc.) peuvent changer du
tout au tout les résultats de ce genre de mesures, donc on reste dans
le domaine de la boule de cristal.