SSD 2009, acte 2 : OCZ Vertex et Indilinx Barefoot

La dégradation des performances

Nous en avions parlé lors de notre précédent article sur les SSD, un SSD « neuf » n’as généralement pas les mêmes performances qu’un SSD utilisé. Commençons tout d’abord par l’usure qui concerne tous les SSD, à savoir la perte de performances lorsqu’on écrit des petits blocs de donnée.

Au sein des 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’écriture 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 quelles sont à l’avance 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, deux conditions sont toutefois nécessaires. D’une il faut un SSD qui supporte cette fonctionnalité, que ce soit à sa sortie ou via un nouveau firmware comme c’est le cas de l’OCZ Vertex, de deux il faut que le système d’exploitation en tire partie. C’est possible dès à présent sous Linux, et pour Windows il faudra attendre Seven, qui ne l’intègre d’ailleurs pas pour l’instant dans ses versions beta.

Autre solution, OCZ propose un utilitaire en version beta à destination des Windows 32 bits permettant d’utiliser la fonction TRIM du SSD. Il ne s’agit pas ici de l’utiliser à la volée mais lorsqu’on lance l’utilitaire, celui-ci lit la table d’allocation du système de fichier et indique au SSD via la commande TRIM les adresses LBA qui ne sont pas utilisées. Et voilà !