SSD 2009, acte 2 : OCZ Vertex et Indilinx Barefoot

L’usure du Vertex en pratique

Voici un exemple pratique de la dégradation des performances d’un SSD avec le Vertex 30 Go lorsque la fonction TRIM n’est pas utilisée.

Cas 1 : Performances séquentielles - Accès séquentiels uniquement

Tout d’abord, voici les débits (en Ko /s) en écriture et lecture séquentielles lorsqu’on n’effectue que des accès de ce type (une lecture, une écriture, une lecture, une écriture, une lecture et une dernière écriture, à chaque fois sur l'intégralité du SSD soit 30 Go) :


On note une légère baisse de performances entre un disque neuf et un disque utilisé, puisque l’on passe de 206 à 196 Mo /s en lecture et de 159 à 145 Mo /s en écriture. Pas de quoi fouetter un chat toutefois.

Cas 2 : Performances séquentielles - Accès aléatoires puis accès séquentiels

Cette fois on part d’un disque neuf (après HDD Erase ou flashage) que l’on « use » en écrivant uniquement par bloc de 4 Ko de manière aléatoire, pendant 30 minutes.


Les performances en lecture séquentielle sont dégradées dès le premier run. Pire, la seconde lecture qui a lieu après la première écriture séquentielle offre des performances encore plus basses, qui commencent à remonter au 3è passage. Les moyennes en lecture sont ainsi de 148, 93 et 116 Mo /s, à comparer aux 206 Mo /s obtenus dans le meilleurs des cas sur un SSD « neuf ».

En écriture, c’est encore pire, et ce dès que l’on essaie d’écrire en séquentiel avec une table d’allocation auparavant utilisée pour une écriture aléatoire : 25.6 Mo /s dans un premier temps, débit qui remonte progressivement à 40.8 puis 50 Mo /s. Lentement, et difficilement, la table d’allocation se réorganise.

Cas 3 : Performances aléatoires

Voici maintenant une observation de l’évolution des performances (en I/O par seconde) lors d’écriture de fichier de 4 Ko de manière aléatoire. On lance le test sur le SSD Vierge, 6 fois 5 minutes, puis une seconde fois sur un SSD ont les cellules ont auparavant été remplies de manière séquentielle.


Le problème qui se pose ici est donc la valeur que l’on doit inclure dans un test : certains diront qu’un Vertex fait 3270 I/O par seconde, alors qu’on est rapidement loin de cette valeur même sur un Vertex tout neuf. Sur un SSD qui a été préalablement rempli, les performances baissent toujours, mais la courbe est cette fois stabilisée.

L’utilitaire TRIM

Voyons voir ce que peut faire l’utilitaire TRIM développé par Indilinx contre ce phénomène qui n’est pas sans nous refroidir vis-à-vis comme c’était le cas avec le SSD Intel X25-M. Ce logiciel se lance simplement sous Windows XP ou Vista 32 bits, son fonctionnement en 64 bits n’était pas encore complètement stable. Une fois lancé il envoie 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à ! Que ce soit en lecture séquentielle, écriture séquentielle, ou écriture aléatoire, les performances du Vertex reviennent alors à leur niveau d’origine. Voilà donc une très bonne nouvelle qui laisse présager du meilleur quand la fonction TRIM sera implémentée directement au niveau du système d’exploitation et qu’elle se fera à la volée. En attendant, ceux qui possèdent un Vertex et qui remarquerait une baisse notable de leurs performances n’auront plus qu’à utiliser l’utilitaire pour ramener les performances d’origine sur l’espace libre restant.