SSD, TRIM et IOMeter

La dégradation des performances

Nous en avions parlé dès notre premier article sur les SSDs, un SSD "neuf" n’as pas les mêmes performances qu’un SSD utilisé, ses performances se dégradant au fil de son utilisation. Deux phénomènes expliquent ce fait, commençons tout d’abord par l’usure qui concerne tous les SSDs, à savoir la perte de performances lorsqu’on écrit des petits blocs de données.

Dans les puces Flash NAND, les cellules mémoires sont regroupées au sein de pages, ces pages composant des blocs. Généralement une page fait 4 Ko, un bloc fait 512 Ko. Il faut savoir qu’il est possible de lire ou d’écrire une puce Flash NAND par page, mais que les données ne peuvent être effacées que par bloc.

Autre paramètre à prendre en compte, lorsqu’un fichier est effacé par le système, le SSD n’est tout simplement pas au courant, puisque l’opération se situe uniquement au niveau du système de fichiers. Le SSD n’a donc connaissance de l’invalidité d’une donnée contenue dans une page qu’à partir du moment où l’on va réécrire dessus !

Le phénomène qui en découle est du coup assez simple : lorsque l’on va écrire un nouveau fichier de 4 Ko sur une page déjà utilisée, le SSD va alors devoir lire le bloc entier, puis l’effacer, et enfin réécrire toutes les pages de ce bloc. Pour une écriture de 4 Ko, on aura donc jusqu'à 512 Ko de lecture, une phase d’effacement et 512 Ko d’écriture, ce qui a logiquement un impact négatif sur les performances, particulièrement lors de l’écriture aléatoire de fichiers de petite taille.

Autre problématique, l’adressage des pages mémoire Flash utilise un système indirect, le contrôleur faisant office de traducteur entre les adresses logiques utilisées par le système de fichiers (les LBA) et les adresses physiques des pages Flash correspondantes. La correspondance n’est en effet pas fixe comme c’est le cas des disques durs, le contrôleur Flash se chargeant d’allouer au mieux les pages afin d’optimiser les performances (write combining) ou d’améliorer la durée de vie des cellules (wear leveling).

C’est surtout un write combining agressif qui peut ici poser problème. Le write combining fonctionne de manière assez simple, puisqu’il s’agit de combiner plusieurs écritures aléatoires en une seule écriture séquentielle : écrire d’une traite 32 pages dans un même bloc va bien plus vite que d’écrire 1 page dans 32 blocs différents, et cerise sur le gâteau, cela use moins le SSD. La table d’allocation doit alors être mise à jour pour que LBA 0 = Page 0, LBA 133 = Page 1, LBA 289 = Page 2, etc.…

Seul problème, si on doit ensuite réécrire de manière séquentielle sur le SSD avec une telle table d’allocation, les performances sont alors fortement réduites puisqu'on fera physiquement des écritures non séquentielles ! Bien entendu en fonction du contrôleur le SSD essaie de réorganiser au mieux la table d’allocation pour ce type d’écritures mais sans grand succès si toutes les pages ont déjà été utilisées une fois. Le write combining est d’ailleurs lui-même mis à défaut faute de page libre, puisqu’il ne peut alors plus faire son office faute de matière première.

Vive le TRIM

C’est là qu’intervient la fonction TRIM. Proposée en 2007 par le comité technique T13 qui est chargé de définir les spécifications de la norme ATA, il s’agit d’une commande permettant au système d’indiquer au support de stockage qu’un LBA contient des données qui sont désormais invalides.

Ca peut paraître « bête », mais cela va considérablement simplifier la vie des contrôleurs SSD pour ce qui est de la bonne tenue des performances. Au niveau du contrôleur, l’implémentation n’est pas fixe mais logiquement il s’agira de supprimer la référence à la page dans la table d’allocation LBA / page Flash.

Effacer physiquement chaque page à ce moment, c'est-à-dire lire le bloc entier auquel elle appartient, l’effacer et le réécrire, serait complètement contre-productif du point de vue de l’usure des puces mémoires, mais il est imaginable que tout bloc ne contenant que des pages qui ne font plus partie de la table d’allocation soit remis à 0.


Dans tous les cas, le fait de savoir à l’avance quelles sont les pages disponibles pour une écriture permettra au contrôleur d’optimiser au mieux les écritures, qu’elles soient séquentielles ou aléatoires, et donc de ne plus se retrouver face à la problématique actuelle lorsque toutes les cellules ont été utilisées au moins une fois.

Pour pouvoir utiliser cette fonction, il faut avoir un SSD la supportant mais aussi un système d'exploitation qui en tire partie. C'est le cas de Windows 7, de Linux et bientôt de Mac OS X. Sous Windows XP et Vista, Intel comme Indilinx proposent des outils à lancer de manière régulière qui lisent la table d’allocation du système de fichier et indiquent au SSD via la commande TRIM les adresses LBA qui ne sont pas utilisées.