Récemment, j'ai croisé ce qui avait l'air de gros soucis de performance au niveau d'un miroir ZFS (l'équivalent d'un RAID 1). Je voudrais parler de mon raisonnement et des informations que j'ai pu acquérir sur le sujet afin de résoudre le problème que j'ai rencontré.

Note: Je ne suis pas un spécialiste du fonctionnement des SSDs, surtout quand je commence à détailler des possibles fonctionnements. Certaines parties peuvent avoir des explications de fonctionnement approximatifs ou un peu faussés sur le fonctionnement en détails d'un SSD.

Les symptômes

En terme de symptômes, écrire sur le groupe de SSDs prenait beaucoup de temps, si on compare avec les débits normaux d'un SSD. Le temps d'activité du SSD probématique était pratiquement tout le temps à 100% selon Netdata. Comme la vitesse d'écriture d'un miroir est celui de son disque le plus lent, je vous laisse imaginer les performances ressenties.

Qu'est-ce que cela a entrainé ? Le SGBDR¹ ne répondait plus très bien, ce qui à son tour affecte d'autres logiciels tels que mon serveur de messagerie instantanée décentralisée dont des requêtes HTTP étaient répondues avec 504 Gateway Timeout.

Quelque chose n'allait pas et ça se sentait/voyait clairement.

La recherche

Forcément, j'ai été demander l'avis d'Internet. D'abord, en cherchant un peu par mot-clef. Ensuite, dans des salons à droite et à gauche en posant la même question. J'ai ensuite posé la question plus loin, sur Mastodon.

Le SSD mourant ?

On m'a d'abord relaté la thèse d'un SSD mourant. En effet, cette personne m'a indiqué que les données S.M.A.R.T. (que je noterai comme SMART parce que flemme de mettre des points partout) disaient que le SSD était bon, mais ce dernier a rendu l'âme "peu de temps après". Pour celles et ceux qui ne sauraient pas ce que ce sont ces données SMART, ce sont des informations de diagnostic que le support de stockage collecte sur lui-même. Ces informations permettent d'avoir une idée de l'état de santé du disque et, au besoin, d'effectuer des actions comme le remplacer ou bien commander des disques en avance pour se préparer à une défaillance imminente.

Contrairement à un disque-dur "classique" (HDD ou Hard Disk Drive), un SSD ne dispose pas de parties mécaniques et peut partir sans "rien dire"; juste le kernel qui hurle au disque déconnecté. Un disque-mécanique, même s'il peut partir en silence, il peut commencer à faire des bruits qui signalent qu'il va bientôt claquer.

Du coup, j'étais prêt à commander un SSD quand celui qui m'embête déciderait de me lâcher.

J'ai également fait quelques recherches, le SSD en question, bien qu'il m'ait lâché deux fois et cause quelques petits soucis sur ZFS, devrait tenir d'avantage que trois ans de marche et 55 TB d'écriture.

T'as TRIMmé ton SSD ?

Une autre thèse qui m'a été relatée a un rapport avec le TRIM. Contrairement aux disque-durs mécaniques dont les cellules magnétiques peuvent être réécrites sans autres, les SSDs doivent "effacer" leur cellules de mémoire avant qu'elles puissent être écrites avec d'autres données. Il existe une commande à donner aux SSDs pour qu'ils puissent réinitialiser des cellules sans pénaliser le reste du système parce qu'elle est asynchrone. Elle est également presque transparente quand on a assez de place pour que le contrôleur bouge les données.

Il s'est avéré que, du fait que une option était désactivée dans les paramètres du pool ZFS, les cellules "effacées" mais non réinitialisées commençaient à s'empiler au point que... il n'y avait plus de cellules libres et que les performances prenaient un coup de massue. Je me pose la question: comment le SSD est censé savoir ce qui peut être purgé, s'il purge de lui-même ? Est-ce que le système de fichiers fait réinitialiser les cellules avant d'écrire par dessus, ou bien le SSD réinitialise les cellules avant de les écrire ?

La solution

La solution pour régler ce problème a été dans un premier temps donner la bonne commande au SSD, puis de paramétrer le pool ZFS.

Pour TRIM un pool ZFS, il suffit de lancer la commande zpool trim <le pool>. Sur un système de fichiers plus conventionnel, fstrim fera l'affaire. L'opération permettra de donner un coup de balai sur les cellules "effacées" au niveau du système de fichiers mais encore considérées comme utilisées par le contrôleur.

Ensuite, pour ZFS, il faut activer l'option autotrim avec la commande zpool set autotrim=on <pool>. En ce qui concerne les systèmes de fichiers classiques tels que ext4, il faut mettre l'option discard sur le ou les bons points de montage dans le fichier /etc/fstab.

La différence entre un SSD non trimmé et un SSD trimmé est remarquable. Au moins, je sais à quoi m'attendre si je ne trim pas automagiquement ou régulièrement.

Le mot de la fin

Pour finir, ce n'était pas un SSD mourant qui était en train de m'embêter; c'était un SSD qui était pleine de cellules libres au niveau du système de fichiers mais toujours occupées selon le contrôleur. Ce SSD me le faisait juste savoir d'une manière peu conventionnelle, ou presque.