L’autre jour un « informaticien » me dit, ouah il faut acheter les disques flash, c’est trop de la balle, c’est rapide, fiable, et génial.

 Fiable : pas de pièces mécaniques,
 Rapide : temps d’accès rapide,
 Génial : ça consomme moins qu’un disque.

Je n’ai beau être qu’un facard (maître es science option micro électronique), d’un pays où l’on est sensé être les derniers idiots du monde, j’ai fait mais il va pas bien !

Il y a 8 ans j’ai travaillé sur un produit qui devait avoir des disques flashs, et à l’époque j’ai dit non à son utilisation :

 trop cher ;
 durée de vie trop faible ;
 pas de détection possible des défauts ;
 trop peu d’espace de stockage.

Aujourd’hui, les capacités des disques flashs conformément à la loi de Moore sont suffisantes, et les prix ont baissé. Il ne reste donc qu’un seul élément bloquant : la fiabilité.

La fiabilité pour un disque dur est liée aux pièces mobiles qui avec le temps, les vibrations, les chocs, se détériorent. J’abonde dans le sens que moins de pièces mécaniques et moins de complexité, c’est mieux.

Mais comment marche un disque flash (explication ici) [1] ?

C’est grosso merdo une mémoire vive vue comme un disque, dont on rend les informations persistantes en appliquant des putains de grosses tensions (à l’achelle du semi cond) sur la grille. Un driver et du hardware transforment ensuite ce qui est une bête mémoire vive à accès séquentiel en block device.

Bref, pour graver 0 ou 1 dans une zone vous chargez une capa au limite du claquage. Les cellules ont de fait un nombre limitées de lecture/écriture. En technologie NAND ces chiffres sont un secret industriel qui sont masqués à l’utilisateur par un hardware gérant les zones claquées, des codes de redondances cyclique, de la redondance, de la répartition d’écriture. Autrement dit, le hardware vous masque les défauts de votre périphérique et recopie les zones faillibles à la volée, et reroute les accès aux zones mortes.

Très bien me direz vous.

Bullshit je vous répond. Car voici mon problème :

Les constructeurs expriment la capacité d’utilisation d’un disque flash en MTBF et c’est du pur bullshit

Lire cette interview pour comprendre le foutage de gueule

Le MTBF ou en français Temps Moyen Avant Panne est une valeur temporelle ! De plus je me fous que comme toshiba ou samsung l’avancent ces disques aient une durée de vie de soit disant 10 siècle, si la variance fait que j’ai une chance sur 10 de tomber sur un disque qui durera moins d’un mois ça me fait une belle jambe.

Mais comment Dieu, peut on me faire sérieusement une conversion nombres limites de lectures/écritures fixés en temps ? Il faut pour cela faire déjà une hypothèse du nombres d’opérations de lecture/écritures par seconde.

Pourquoi c’est du bullshit, premièrement les pannes sont directement liées aux nombres de lectures/écritures un serveur de mail ou de base de données sollicités en écriture 1000 fois plus qu’un ordinateur de bureau voient leurs pseudo MTBF logiquement diminués d’un facteur 1000 et encore il peut y avoir des effets de fatigue incrémentés si on sollicite trop une même zone dans un intervalle de temps réduit ! Donc je ne vois pas comment on peut assurer un MTBF en ayant des profils de volumes de données ayant des variances de 1000.

Donc adieu les 1000 ans, bonjour le disque qui claque en 1 an.

Ensuite, il font l’hypothèse d’une répartition des données équiprobable aidées par leur logique cablée sur toute la surface de la mémoire. Or, le système de fichier en a que foutre. Il fait lui même des optimisations de placement de blocs, et je ne peux imaginer aucun algorithme pour le microchip de la flash capable de faire bien pour tous les systèmes de fichiers.

Donc vous devez pour pas avoir de surprises installer un système de fichier adapté et ainsi adieu les zfs, reiserfs, système de fichiers journalisés.

Enfin, cette couche transparente pour le système de fichier est un logiciel de fait qui est complexe. Complexité = bug = panne.

Conclusion

Si vous êtes un sysadmin sérieux n’achetez pas de disque flash tant que les fournisseurs ne fournissent pas des données sérieuses sur la fiabilité. Elles doivent indiquer : le nombre de lecture/écriture maximale avant panne probable, elles doivent impliquer des tests de rafales d’écriture (simulant une installation / update de système d’exploitation) le temps que ça donne selon des hypothèses variées d’utilisation, et le système de fichier utilisé.

De plus, rien qu’un serveur syslog ou un serveur de backup, ou de gestion de version est un gouffre à écriture (la partie la plus sensible), je vous déconseille donc d’utiliser les disques flash pour ces serveurs, à moins que vous mettiez /var/ sur un disque dur mécanique et que vous vous assuriez que tous les fichiers qui sont souvent modifiés (spool de mail, backend de db, logs, backup, depôts de sources) soient bien dans ce répertoire.

Si vous préférez on revient au partitionnement à l’ancienne / /bin /usr/ pour un disque dur rapide de taille limité avec des données appelées souvent en lecture (disque flash) /home /var pour des données écrites souvent pour des données souvent modifiées (disque mécanique).

Est-ce que cela vaut vraiment la peine de s’emmerder à nouveau avec ça ?