SSD, TRIM et IOMeter

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 ...