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.