La Distorsion

Le test de disques à la disto

Sommaire

1. Problématique et besoins
2. Panorama des possibilités
3. Historique des solutions
4. Diskeuz, la testeuz du futurz
5. La suite

Problématique et besoins

A la disto, on récupère (souvent) du matériel usé, comme des tours, des laptops, des bizarreries, ou justement, des disques durs.

Ces disques, on veut pouvoir s'en servir pour :

• les donner, à des étudiant.es pour leurs backups par exemple
• nos propres machines, qui ont besoin de stockage (notamment, celles qu'on récupère et qui n'ont pas de disque(s) !)
• et beaucoup d'autres choses :)

Evidemment, pour les utiliser dans des situations à différents degrés de criticité, nous avons différents niveaux d'attentes vis-à-vis de nos disques. En règle générale, un disque dur utilisé pendant 10 ans 90% du temps peut probablement être inutilisable (voire risque de faire perdre des données !).

Il se trouve que tous les disques ne sont pas utilisés de la même façon (tout le monde peut comprendre qu'il y a une différence entre un disque de tour dans un collège, utilisé pour télécharger quelques images de temps en temps, et un disque de serveur très actif qui se fait réécrire plusieurs fois par mois), et que même ils n'ont pas tous la même ancienneté.

Alors, on a eu un besoin d'un protocole (d'abord) et d'une infrastructure (après) pour faciliter les tests et les rendre moins relous. Je détaillerai plus bas les outils qui permettent de tester des disques.

Panorama des possibilités

Mais au fait, comment on fait pour "tester" un disque (dur) ? Je vais utiliser (un peu) de vocabulaire des disques dans la suite de cette section (et dans celle-ci uniquement !). La page wikipedia sur les disques durs est très complète.

S.M.A.R.T - une première idée, sans garanties

Un disque-dur, c'est pas si bête, et son firmware (micrologiciel) peut communiquer à l'ordinateur sur lequel il est branché un grand nombre d'informations. Ce protocole, il s'appelle S.M.A.R.T.. Un disque-dur nous renseignera par exemple, le nombre d'erreurs de lecture/écriture (selon un format propriétaire), le nombre de secteurs réalloués (c'est-à-dire les secteurs détectés comme étant défaillants et qui ont été relocalisés sur l'un des secteurs libres de réserve du disque), ou bien même le nombre d'heures d'activité du disque.

Mieux encore, on peut demander au firmware de réaliser des tests, lui permettant de vérifier son état et de nous informer de façon plus précise dessus.

• Test short : dure environ 2 minutes, vérifie l'état mécanique du disque seulement : franchement, un disque dont le test short fail, c'est poubelle
• Test offline : quasi instantané, permet de mettre à jour les registres S.M.A.R.T., important à faire avant d'aller lire ces registres
• Test conveyance : assez rapide, de l'ordre de la dizaine de minutes, à effectuer après un déplacement des disques (ou à la réception).
• Test long : comme son nom l'indique, il est très long. Ce test permet de vérifier les secteurs du disque et met-à-jour de façon active les registres S.M.A.R.T. : c'est le plus représentatif !

Tout est super, non ? Ben non, le gros problème de S.M.A.R.T. c'est que les valeurs dans les registres obéissent à des logiques propriétaires. Prenons par exemple le registre RawReadErrorRate. Il s'agit d'un taux d'erreurs de lecture à l'échelle du disque.

Déjà, la phrase est floue : un taux d'accord, mais qu'elle est l'unité de temps ? Qu'est-ce qu'on compte, le nombre de secteurs en erreur, le nombre d'octets, le nombre d'erreurs ? En l'état, cette valeur est inutilisable, parce que chaque fabricant de disque peut choisir comment interpréter cette valeur. Il existe à priori une solution: le disque propose des valeurs dites normalisées, ainsi que des indicateurs, des thresholds à comparer à la valeur normalisée pour déterminer si le registre indique un comportement "pre-fail" ou non du disque ("pre-fail", c'est-à-dire que le disque va mourir dans les prochaines 24 heures, selon le contrôleur (et le fabricant)).

Encore une fois, il est difficile de comprendre comment interpréter chaque paramètre, même une fois normalisés, car ils ne sont pas tous aussi importants.

Malgré tout ça, S.M.A.R.T. reste tout de même un assez bon outil; vu que c'est le disque qui se charge de se tester, on n'a pas besoin d'avoir un gros débit entre le disque et la machine qui le teste: une baie USB suffit. En plus la durée des tests, mêmes longs, est généralement faible (quelques heures), ce qui permet de multiplier les tests et d'aller assez vite.

Il existe pas mal de ressources sur l'Internet sur comment interpréter les résultats S.M.A.R.T., mais c'est compliqué de s'y retrouver. Quelques liens que je trouve pas mal:

• Une question sur StackExchange
• La page de documentation de S.M.A.R.T. de Arch Linux, pour configurer smartd
• La section de la page Wikipedia qui liste les registes (attributs) S.M.A.R.T. avec une description
• Un article de blog qui donne de très bonnes ressources

Badblocks - la solution qui marche à tous les coups

J'en ai rapidement parlé, l'important quand on teste un disque-dur, c'est l'état des secteurs. Badblocks est un outil qui permet de tester l'état du disque en balayant ses secteurs par blocks, c'est-à-dire un découpage logiciel du disque-dur. Un block, ça ne fait pas forcément la taille d'un secteur. Le fonctionnement de badblocks est très simple. Le logiciel va réaliser plusieurs passes, durant lesquelles il écrit un motif (le même, partout) dans chaque bloc. Une fois la première passe d'écriture terminée, badblocks réalise la première passe de lecture, Reading and comparing. L'algorithme est simple : si badblocks lit dans un bloc quelque chose d'autre que le motif qui a été écrit, on ajoute 1 aux nombres de "badblocks", de blocs défectueux. Et rebelotte pour toutes les passes !

C'est super et ça donne une réponse très claire. Si il y a plus de 0 badblocks, le disque est en mauvais état, point final. Le seul souci, c'est que contrairement à S.M.A.R.T., le test se passe cette fois sur le l'ordinateur, et sa vitesse est déterminée par la vitesse de la connexion au disque et celle du disque.

En pratique, badblocks est très, très, très lent sur une baie de disques USB : il faut utiliser un serveur fait pour traiter un grand nombre de disques en parallèle pour que le test soit efficace.

Note sur les SSD
Un SSD, c'est vraiment différent d'un disque-dur, et ça se teste pas pareil. En général, les infos S.M.A.R.T. ont tout ce qu'il faut (pourcentage d'utilisation du SSD par exemple), et il ne faut vraiment pas utiliser badblocks dessus : ça l'use beaucoup ! Comme on en récupère pas beaucoup, cet outil ne s'en occupe pas du tout (et cet article de blog non plus)

Historique des solutions

Historiquement, on a utilisé un petit PC avec une baie de disques attachée en USB et réalisé des tests S.M.A.R.T.. Ces tests, on les suivait à l'aide d'un outil web (pour avoir une interface graphique plus facile à expliquer que la sortie de smartctl dans un terminal) nommé Scrutiny un peu modifié.

Ce système fonctionnait bien, néanmoins Scrutiny est vraiment très peu adapté à notre usage, en plus du caractère non-standard des registres S.M.A.R.T.

Diskeuz, la testeuz du futurz

Contexte

Cet été on a récupéré beaucoup de disques, tellement qu'il fallait s'y mettre sérieusement. En plus, on a finalement décidé que S.M.A.R.T. c'était pas suffisant pour nous, parce qu'on voulait des garanties fortes sur l'état des disques qu'on testait.

On a sorti un gros serveur, avec plein de baies, installé Debian et un logiciel trouvé sur GitHub nommé bht. C'est un simple script qui permet de lancer des tests badblocks, de les suivre, et de collecter des informations S.M.A.R.T. avant et après le test.

Protocole

Comme je l'ai dit dans l'introduction, trouver un logiciel pour les tests c'était le plus facile, la vraie difficultée c'est de trouver un protocole de tests. Notre fonctionnement est le suivant :

1. Réception du disque Grâce à notre imprimante à stickers, on pose sur le disque un sticker avec les informations suivantes
   • Sa capacité
   • Sa vitesse de rotation
   • Trois mots suffisamment espacés pour pouvoir être entourés : PASS, BADBLOCKS, FAIL
   • Le nom du lot (batch) dont le disque fait partie
2. Démarrage d'un test On récupère dans la caisse à disques à tester, assez de disques pour remplir la baie de tests, puis on les rentre dans la machine. On lance le test (avec une certaine commande).
3. L'attente… Les tests badblocks, c'est long. Sur des disques de 2To, le test prenait jusqu'à 72h à se compléter par disque, avec 12 disques en parallèle
4. Déchargement Notre outil nous fournit un fichier contenant, pour chaque disque, deux informations :
   • Son état calculé pour Badblocks : PASS, BADBLOCKS, ou FAIL
     • Une grande partie du travail était de déterminer quand un disque tombe dans chaque catégorie
     • 0 badblocks, c'est PASS
     • Plus de 0, mais moins de 10, c'est BADBLOCKS
     • 10 et au delà : c'est FAIL
   • Son état calculé pour smartctl : PASS ou FAIL
     • Là aussi, déterminer les valeurs pivots qui rendent un disque défectueux n'était pas facile, voici ce qui fonctionne pour nous:
     • Valeur (normalisée) du RawReadErrorRate inférieure à son threshold : FAIL
     • Valeur (normalisée) du MultiZoneErrorRate inférieure à son threshold : FAIL
     • Valeur (raw) de OfflineUncorrectable supérieure à 0 : FAIL
   L'idée, c'est qu'un disque peut être bon selon badblocks, mais pas selon S.M.A.R.T. et vice-versa. Pour chaque disque, on entoure ensuite la pire valeur et on le range avec les disques testés (idéalement, dans une caisse où tous les disques sont dans le même état)
5. On continue !

Ce protocole est assez simple, mais nous a vraiment beaucoup aidé.es cet été. En plus, définir à l'avance trois catégories d'états (PASS, BADBLOCKS, FAIL ) nous force à choisir une fois le disque testé et les informations S.M.A.R.T. et Badblocks recueillie : pas de place pour mettre un petit mot d'hésitation ou autre.

Pourquoi l'état BADBLOCKS ?
L'état "BADBLOCKS" permet de conserver quelques disques qui n'ont certes pas de bonnes garanties de santé, mais qui pourraient toujours être utiles. On ne s'en sert pas uniquement pour les disques pour lesquels Badblocks renvoie autre chose que 0.

L'outil !

Notre nouvel outil, c'est une configuration NixOs qui s'appelle Diskeuz.

Pourquoi NixOs ?
On a pas toujours une baie de disque disponible pour tester des disques, du coup, c'est plutôt pratique de pouvoir installer une testeuse de disque en quelques minutes sur une machine qu'on a sous la main !

Cette configuration contient pas mal de choses :

• Le programme bht que nous avons modifié
  • Par l'ajout de quelques informations S.M.A.R.T.
  • Par la suppression du système de mails
  • Par l'ajout de quelques commandes pour simplifier son utilisation
  • Par l'ajout du calcul automatique de l'état du disque selon S.M.A.R.T(ctl) ou Badblocks
• Un système d'arrêt automatique du système une fois les tests finis, et qui dépose les fichiers contenant les informations de chaque disque sur notre serveur DUFS local
• Une documentation intégrée pour pouvoir l'utiliser rapidement

La suite

Parce qu'on fait toujours les choses sur du matériel un peu shlag, Diskeuz est loin d'être un produit fini. Déjà, le parti pris de se concentrer sur badblocks, c'est cool quand on a une grande baie de disques, mais en temps normal on doit se contenter de la petite baie USB. Dans ce cas, adapter Diskeuz pour poivoir utiliser uniquement S.M.A.R.T., ce serait mieux. En plus, bht ne lance pas de tests S.M.A.R.T. sur les disques (dans sa forme actuelle), donc les attributs S.M.A.R.T. auxquels nous avons accès ont une pertinence limitée. Avoir un outil capable de très bien gérer S.M.A.R.T., ce serait donc une première piste d'amélioration.

Ensuite, Diskeuz est loin d'être parfaite; notre version de bht contient des bugs parfois difficiles à diagnostiquer. Au delà de la question des bugs, même après avoir fait tout notre possible pour rendre l'outil facile à utiliser, ça reste compliqué de se passer de la ligne de commande. Une autre piste d'amélioration serait d'ajouter des règles udev pour démarrer les tests automatiquement lorsque les disques sont insérés dans la baie, les autres opérations étant déjà automatisées.

Comme j'en ai aussi déjà parlé, on ne s'est pas du tout intéressé.es aux disques SSD pour l'instant. C'est aussi un manque à combler, parce qu'on peut être emmené.es à en récupérer et pour l'instant on n'a aucun savoir-faire sur ce type de média. C'est moins prioritaire, certes, mais être capables de tester tous types de disques rapidement et surtout en étant confiant.es sur le résultat, c'est vraiment une force pour nous.

Et puis, il reste aussi la question de la validation de notre processus. Pour l'instant, nous n'avons pas pu avoir de retours sur les disques ayant passés nos tests. Peut-être qu'on est trop "sympas" sur les critères, et qu'il faudrait en jeter plus ? Ou au contraire, on a tellement peur d'un mauvais disque qu'on est trop conservatifs sur les résultats (ce qui est moins un problème lorsqu'on récupère beaucoup de disques, évidemment).

L'aventure Diskeuz est bien sûr ouverte à tous.tes :) Que ce soit pour rentrer des disques la baie, aider au code, ou faire des retours sur les disques, toute aide est bienvenue !

PS: On fait quoi des disques "FAIL" ?

Quand on est certain.es qu'un disque est mort, on peut encore en faire des trucs. Par exemple à la disto, on fabrique des patates à facettes :)