HardWare.fr


SSD, TRIM et IOMeter
StockageSSD
Publié le Jeudi 29 Avril 2010 par Marc Prieur

URL: /articles/791-1/ssd-trim-iometer.html


Page 1 - Introduction



Depuis maintenant deux ans, les SSD ne cessent de se démocratiser. Bien que leur progression dans nos machines soit quelque peut freinée par les prix de la MLC qui restent à des niveaux élevés, ils ont marqué une progression fulgurante de la vitesse du système de stockage des PC.


Alors que de nouveaux contrôleurs arrivent sur le marché, nous avons voulu faire le point sur la fragmentation des SSD, le TRIM, la manière dont il est utilisé sous Windows 7, ainsi que sur IOMeter, un logiciel de test synthétique puissant mais qui peut être utilisé à mauvais escient lorsqu’il s’agit de tester des SSDs.
Retour vers le futur
Nous avons publié depuis septembre 2008 sept articles dédiés aux SSD :

- Comparatif SSD : Intel, OCZ, Samsung, Silicon Power, SuperTalent - 8 Septembre 2008
- Mtron MOBI 3500 - 1er Décembre 2008
- SSD Samsung MLC 64 Go - 8 Décembre 2008
- SSD 2009, acte 1 : OCZ Apex et Samsung PB22-J - 16 Mars 2009
- SSD 2009, acte 2 : OCZ Vertex et Indilinx Barefoot - 22 Avril 2009
- Intel X25-M, round 2 : 10 SSD comparés - 5 Mai 2009
- Intel X25-M V2 (Postville) - 31 Juillet 2009

Dès le premier, nous avions pointé du doigt un phénomène plus ou moins important selon le modèle de SSD, qui était une dégradation des performances au fil de l’usage du SSD. La fonction TRIM, implantée dans Windows 7 depuis sa sortie, était attendue comme le messie puisqu’elle était censée prévenir une telle usure. Qu’en est-il en pratique ? Avec un peu de retard il est vrai, nous revenons à l’occasion de la mise au point de notre nouveau protocole de test de SSD sur le TRIM ainsi que l’impact qu’il a sur certains logiciels de tests tels que IOMeter.


Page 2 - Dégradation & TRIM, la théorie

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.


Page 3 - Dégradation, la pratique

Dégradation des performances, la pratique
Que donne l’usure en pratique ? C’est un sujet que nous avons déjà abordé, mais afin d’avoir une idée précise nous avons mesuré l’usure d’un SSD Crucial M225 64 Go à base de SSD Indilinx avec le dernier firmware.

Pour commencer, voici les performances en lectures séquentielles obtenues sur le SSD vierge de toute utilisation puis sur un SSD fragmenté par seulement 12 minutes d’accès aléatoires en écritures de 4 Ko sous IOMeter, soit environ 10 Go de données écrites de cette manière :


De base, le débit moyen est de 215,5 Mo /s en lecture, mais il chute à 162,7 Mo /s sur le SSD fragmenté. Voici maintenant les chiffres en écriture :


De 159,9 Mo /s à neuf, on retombe à 106,6 Mo /s. Sur 1/3 du SSD, le débit reste à 160 Mo /s, puis varie entre 80 et 100 Mo /s jusqu’à 90% du SSD, avant de chuter sur la fin entre 25 et 30 Mo /s.

Voici maintenant les performances en écritures aléatoires de 4 Ko obtenues pendant 12 minutes sur le SSD vierge de toute utilisation puis sur un SSD préalablement écrit de manière séquentielle par h2bench :


L’impact sur les performances est également très important ici !


Page 4 - TRIM sous Windows 7, la pratique

TRIM sous Windows 7, la pratique
Pour pouvoir utiliser le TRIM sous Windows 7, il faut disposer d’un SSD qui supporte le TRIM bien entendu, mais aussi de drivers du contrôleur IDE ou AHCI qui sont compatibles avec le TRIM, c'est-à-dire qui laissent passer la commande TRIM depuis Windows vers le SSD.

C’est le cas des drivers IDE/AHCI génériques de Windows 7, mais également des drivers Intel RST depuis leur version 9.6, ce qui permet du coup d’avoir le TRIM sur un SSD même si vous avez à côté de ce dernier un RAID de disques durs. A contrario les drivers Marvell et AMD ne sont pas compatibles TRIM pour le moment, et il est donc préférable d'utiliser les drivers génériques Microsoft. (Mise à jour : les pilotes AMD et Marvell sont désormais compatibles TRIM !)

Dans quel cas est-ce que la commande TRIM est active ? Pour ce faire, nous avons mesuré les performances obtenues en écritures aléatoire 4 Ko sous I/O Meter dans diverses conditions. Pour rappel, sur le SSD Vierge nous obtenons dans ce test 11,8 Mo /s, et 2,5 Mo /s lorsqu’il a été usé par une écriture séquentielle complète.

Si on effectue une écriture séquentielle complète sur le disque, que l’on conserve le fichier résultant de cette action, puis que l’on supprime la partition, les performances ne sont pas rétablies et restent à 2,5 Mo /s.

Si on effectue une écriture séquentielle complète sur le disque, que l’on efface le fichier résultant de cette action, les performances sont rétablies et atteignent 11,8 Mo /s.

Si on effectue une écriture séquentielle complète sur le disque, que l’on supprime la partition puis qu’on la recrée avec un formatage rapide, les performances sont rétablies à 11,8 Mo /s.


Les performances en écriture séquentielle après des écritures aléatoires sont également rétablies après formatage ou suppression du fichier :


Comme vous pouvez le voir, Windows 7 envoie la commande TRIM au SSD dans deux cas :

- Lors du formatage de la partition, même si c’est un formatage rapide
- Lors de la suppression d’un fichier


Bien entendu dans le premier cas, c’est tout le SSD qui est réinitialisé, alors que dans le second cas seul les pages de la Flash concernées par les fichiers le sont. Il faut noter que du coup le formatage rapide prend un peu plus de temps du fait de l’envoi de la commande TRIM, il prend environ 30 secondes.


Page 5 - IOMeter et SSD, attention !

IOMeter, un outil puissant mais complexe

Nous voulons profiter de cet article dédié au TRIM et de la mise au point de notre nouveau protocole de test pour mettre en garde contre l’utilisation de IOMeter pour les tests de SSD. Développé par Intel puis repris dans le cadre de l’Open Source, IOMeter est un outil de test synthétique aussi puissant que complexe à utiliser. Initialement prévu pour les disques durs, il peut être utilisé pour tester les SSDs mais il nécessite alors des réglages sans quoi les résultats obtenus peuvent être plus ou moins inexacts.

Le premier point problématique se situe au niveau de la typologie des accès intégrés par défaut dans IOMeter. Ces derniers sont en effets configurés par défaut pour être alignés sur un secteur, c'est-à-dire 512 octet, un alignement non correct comme c’est le cas sous Windows XP avec une partition non alignée manuellement. L’impact peut être important puisque par exemple une simple écriture de 4 Ko sera à cheval entre deux pages de 4 Ko du SSD, il lui faudra donc écrire ces deux pages.


Une partie des SSDs résolvent ce souci au niveau du contrôleur en ré-adressant les accès du système pour qu’ils soient alignés avec les pages des puces Flash, mais ce n’est pas le cas de tous et ce n’est dans tous les cas plus représentatif de ce qui se passe sous un OS moderne qui utilise un alignement optimal pour les SSD (c’est le cas depuis Vista chez Microsoft). Il est donc impératif de configurer les options des accès utilisés pour tester sous IOMeter pour qu’ils soient alignés sur une page, soit 4 Ko.

Sur certains SSDs, l’impact du réglage par défaut peut être dramatique, puisque par exemple sur le Crucial C300 en écritures aléatoires de 4 Ko et avec 3 commandes concurrentes nous obtenons 16 Mo /s avec le réglage par défaut et … 129,2 Mo /s en alignant correctement les accès !


Le second point problématique d’IOMeter se situe au niveau de son intégration dans un protocole de test censé prendre en compte le TRIM. En effet, de base, IOMeter permet de tester un SSD (ou un HDD) qu’une partition soit présente ou non sur ce dernier.

Si le SSD n’est pas partitionné, les tests sont lancés directement, mais les accès ne passent pas par la gestion de fichier de Windows 7, et du coup aucune commande TRIM n’est envoyée au SSD par ce dernier. Il faudra donc le faire manuellement entre chaque test, via la création et le formatage d’une partition par exemple, pour avoir des chiffres représentatifs d’une utilisation sous un OS utilisant le TRIM. C’est ici un problème commun à tous les logiciels outrepassant le système de fichier pour les tests, comme par exemple HD Tach ou H2benchw.

Si le SSD est partitionné, ce n’est pas vraiment mieux. En effet, avant de lancer les tests voulus, IOMeter va créer de manière séquentielle un fichier remplissant l’espace disque disponible du SSD. Il exécutera ensuite les tests, sans jamais effacer ce fichier, même quand on quitte IOMeter (il faut l'effacer manuellement).

De fait, même si on veut tester les performances en écritures aléatoires, la mesure se fera sur un support préalablement usé de manière séquentielle, ce qui n’est pas sans conséquence sur les performances sans compter que ce n’est pas représentatif des performances réelles dans un environnement « TRIM ». On obtient ainsi sur un Crucial M225 2.5 Mo /s en écritures dès la première utilisation du bench, au lieu des 11.8 Mo /s qui peuvent être obtenus normalement.


De plus, si on enchaine les tests au sein d’une même session, ils se feront sur un SSD fragmenté de diverses manières, avec un impact qui peut être important sur les résultats obtenus. Le fichier n’étant jamais effacé par IOMeter, on peut écrire un volume infini de données à la suite sur un SSD sans que la commande TRIM soit utilisée, ce qui ne correspond en aucun cas à une utilisation réelle ...


Page 6 - Conclusion

Conclusion
Avant de nous lancer dans un comparatif abordant des technologies aussi récentes et sensibles que les SSDs, il nous parait très important de bien connaitre et exposer les tenants et aboutissants de ces derniers. Nous n’avons pas pour habitude de rentrer à chaque fois dans les détails qui orientent nos choix au sein d’un protocole de test, mais l’arrivée de la commande TRIM rend encore plus délicate sa mise au point et nécessite d’adapter les outils de tests.


IOMeter est l’exemple typique d’un outil de test mis au point à l’époque du disque dur et qui nécessite quelques ajustements afin de représenter les performances réelles d’un SSD sous système d’exploitation moderne, encore plus si ce dernier gère le TRIM, faute de quoi les résultats obtenus peuvent être dans certains cas très éloignés de la réalité.

D’un point de vue plus pratique, on ne peut que saluer l’arrivée de la fonction TRIM et sa bonne prise en charge sur le contrôleur Indilinx. Il faut préciser que nos premiers tests sur SSD Intel montrent un comportement similaire, et nous ne manqueront pas bien entendu pour chaque SSD testé de vérifier la bonne utilisation de cette fonction, mais aussi les performances obtenues sans TRIM.

Notre protocole de test étant quasiment au point, il est temps de passer aux choses sérieuses … rendez-vous dans les prochaines semaines pour un dossier comparant les derniers SSD à la mode !


Copyright © 1997-2024 HardWare.fr. Tous droits réservés.