TRIM, GC et SSD : le point

Préambule : il y a environ 18 mois, au moment de l'introduction de la commande TRIM, nous avions écrit un article sur l'intérêt de la technologie et son fonctionnement exact. Il nous a paru intéressant, au moment où la majorité des SSD supportent cette commande, de revenir sur cette technologie. Rappelons que Windows 7, son pendant « serveur » et Linux supportent la commande TRIM. Pour Mac OS X, il faudra attendre Mac OS X 10.7, Lion.

Un problème de gestion de l'usure

Avant de voir comment régler le problème, voyons d'où il vient. Typiquement, les SSD travaillent avec une table d'allocation qui n'est pas synchronisée avec le système de fichier : écrire un fichier au début du système de fichier n'écrit pas nécessairement le fichier à cet endroit sur le SSD (il n'y a même pas à proprement parler de début et de fin). De plus, les algorithmes de gestion de l'usure font que connaître l'endroit exact où un fichier est écrit est impossible de façon simple. Dans les faits, le système est donc incapable de connaître la structure exacte du SSD. Nous allons voir que c'est important. La perte de performances, qui survient sur les SSD utilisés de façon intensive, est due aux algorithmes de gestion de l'usure : le SSD, quand on va écrire un fichier, va cherche la puce de mémoire la plus apte à recevoir une écriture (les différents algorithmes sont expliqués en détail dans cet article), et c'est là que le bât blesse. Comme nous l'avons vu, le SSD et le système de fichier sont indépendants, et le SSD ne peut connaître qu'une chose sur une donnée : si elle a été écrite au moins une fois ou si elle est vide. Petit problème, l'effacement utilisé habituellement dans un système de fichier (comme NTFS, HFS+, etc.) n'efface pas les données, l'emplacement est simplement marqué comme disponible pour le système, mais le SSD ne peut pas le deviner. Avec le TRIM, le choix des cellules est plus simple, étant donné que le contrôleur sait parfaitement où sont les cellules libres et qu'il n'y a donc pas de phase de recherche pour trouver l'endroit adéquat. Autre point intéressant, il y a un gain au niveau des écritures : typiquement, un SSD est capable d'effacer des données au niveau d'un « bloc » (généralement 256 ou 512 ko) mais écrire ou lire des données au niveau d'une « page » (2, 4 ou 8 ko). Sans TRIM, la modification d'un octet dans un fichier demande donc la lecture d'un bloc, la modification d'un octet et la réécriture du bloc complet, le contrôleur ne connaissant pas l'état des données. Avec le TRIM, il est possible d'écrire directement dans une page, si elle est indiquée comme vide. En pratique, le TRIM permet de garder des performances correctes dans le temps et — au pire — remettre un SSD « à zéro » en envoyant la commande TRIM sur tout le SSD (via le formatage rapide de Windows, par exemple).

Le TRIM

La solution la plus évidente, elle vient de la norme ATA8, et elle est intégrée à Windows 7 et Linux, et bientôt à Mac OS X. Si le SSD perd du temps à chercher au hasard des fichiers supprimés, donnons-lui la possibilité de trouver les fichiers en question facilement. Sitôt dit, sitôt fait, tout du moins quand toute la chaîne est compatible. Concrètement, le TRIM consiste à indiquer au SSD que les données sont effacées, contrairement à la technique habituelle qui consiste à marquer les données supprimées sans les effacer réellement et sans que le SSD puisse le savoir. Avec le TRIM, le SSD est capable de voir où sont les données effacées et donc évite de chercher à les trouver. L'intérêt, c'est que passer la commande est simple : elle ne nécessite pas de ressources spécifiques. En effet, c'est un simple indicateur qui va permettre au SSD de mettre à jour sa table interne et lui permettre de connaître le statut d'une cellule. Il n'y a pas d'effacement physique des données, le fonctionnement au niveau du système d'exploitation ne change pas mais le contrôleur du SSD sait maintenant si une cellule est effacée (logiquement). 

Un problème dans la chaîne, rien ne va

Le principal problème du TRIM, c'est que toute la « chaîne » doit supporter la commande. On doit donc avoir un système d'exploitation qui supporte le TRIM, un pilote de contrôleur SATA qui accepte la commande et un SSD qui l'interprète. SI pour le premier et le dernier point, c'est assez simple — tous les SSD récents supportent le TRIM et WIndows 7 aussi — c'est plus gênant pour le second. En effet, certains pilotes ne laissent pas passer la commande, ce qui bloque la commande. Si Intel ou tout simplement Microsoft proposent des pilotes compatibles, ce n'est pas nécessairement le cas sur d'autres contrôleurs. De plus, les contrôleurs RAID ne laissent pas passer la commande TRIM et les systèmes à base de RAID0 ne peuvent donc pas tirer parti de la commande.

Le Wiper, solution intermédiaire

Avant le TRIM, Indilinx proposait une solution intermédiaire, qui avait l'avantage d'être utilisable avec la majorité des Windows, le Wiper. Le Wiper est un petit programme, utilisable sur certains SSD (en fonction du firmware) qui sert en fait à synchroniser le SSD et le système d'exploitation. Cas simple : vous avez un SSD de 32 Go, que vous avez rempli avec votre système d'exploitation et un fichier provenant d'un DVD que vous avez compressé. Sans le TRIM, supprimer le fichier est une action que le SSD ne verra pas, pour lui, il est toujours là. Le Wiper sert à faire correspondre la base du système de fichier avec la base du SSD, pour lui faire comprendre que le fichier a été supprimé. Défaut de la technique (outre des bugs sur les Windows 64 bits), il faut lancer le programme périodiquement, ce n'est pas automatique. De plus, le Wiper n'est utilisable qu'en NTFS (une version Linux, en bêta, existe malgré tout). Dans la pratique, c'est plus une solution pour revenir à la normale qu'une façon pérenne de corriger le problème.

Le Garbage Collector, façon Samsung

La dernière solution, c'est le Garbage Collector. Concrètement, on est ici entre le TRIM et le Wiper : c'est le SSD qui va réorganiser ses données, seul, pour optimiser le fonctionnement. Deux solutions sont a priori utilisée, et celle de Samsung est la plus intéressante : installée sur les PB22-J et ses clones, elle permet d'effectuer le même travail que le TRIM, mais en arrière-plan. En fait, Samsung a intégré un Wiper automatique dans ses SSD, avec un réarrangement des données quand le SSD n'est pas utilisé. Deux écueils subsistent : l'ensemble est lié au système de fichier NTFS (ce qui limite son efficacité à Windows) et surtout, Samsung ne propose pas de mises à jour pour ses SSD en dehors des partenaires OEM. Dans les faits, la solution est efficace sous Windows, tout en étant moins intéressante que le TRIM : le SSD travaille en arrière-plan, ce qui a le défaut d'augmenter la consommation de façon invisible, et si le SSD est très utilisé, la fonction ne s'active a priori pas.

Le Garbage Collector, façon Indilinx

Dans les derniers firmwares Vertex, OCZ propose une version alternative qui intègre, à la place du TRIM, un Garbage Collector. Concrètement, le système est différent de celui de Samsung, l'ensemble étant conseillé aux utilisateurs de systèmes qui n'utilisent pas le NTFS comme système de fichier (Linux, Mac OS X, etc.). Le fonctionnement exact n'est pas connu, mais il semble que la technologie utilisée permette de réorganiser les données sur le SSD pour optimiser les performances. Dans la pratique, et pour peu qu'il reste suffisamment d'espace libre, les pertes de performances devraient se faire rare, même si une véritable gestion du TRIM serait un plus. Reste que cette technique est plus, comme le Wiper, une solution intermédiaire, en attendant une véritable gestion du problème au niveau du système d'exploitation. C'est mieux que ne rien faire, mais moins bien que le TRIM, avec aussi le même problème que la solution de Samsung, le travail en arrière-plan du SSD peut avoir un impact sur la consommation, un problème gênant dans un PC portable.

Actuellement (février 2011), le TRIM est généralement bien supporté par tous les SSD du marché, ce qui n'est malheureusement pas le cas de tous les contrôleurs. Globalement, il vaut mieux utiliser un port SATA lié au chipset Intel (quand vous avez une plateforme Intel) ou utiliser les pilotes génériques de Microsoft quand vous travaillez sur un connecteur SATA relié à un autre contrôleur (AMD, Marvel, etc.). Pour le système d'exploitation, Windows 7 et Linux prennent en charge le TRIM, Mac OS X (10.6) n'est par contre pas compatible.

Posez une question dans la catégorie Les news : vos réactions du forum
Cette page n'accepte plus de commentaires
10 commentaires
    Votre commentaire
  • Ou plus simple, ne pas installer le driver du contrôleur et laisser le contrôleur générique du système comme ça on a le TRIM sur GNU/Linux et Windows sur plateforme Intel et AMD.
    1
  • Il me semble que Marc d'HFR avait fait une news indiquant que les chipset AMD supportaient bien le trim depuis un moment, même s'ils n'ont pas communiqué publiquement sur ce support.

    Le gros carton rouge est à donner à Nvidia qui a complètement abandonné le support de ses chipset.
    1
  • "Pour Mac OS X, il faudra attendre Mac OS X 10.7, Lion."
    Et encore, on ne sait pas si ça sera limité aux modèles proposé en option à l'achat des macs ou si tous les SSD qui déclarent le gérer vont en profiter.
    Les premiers témoignages de testeurs de la béta de Lion ont l'air de montrer que seuls certains SSD ont droit au TRIM. A voir si ça reste pareil avec la version finale.


    "et — au pire — remettre un SSD « à zéro » en envoyant la commande TRIM sur tout le SSD (via le formatage rapide de Windows, par exemple)."
    Ha bon? Je croyais que le formatage rapide de windows se contentait de n'écraser que le registre de fichier sur le disque/SSD surtout que pour les SSD, il y a une autre commande dont le rôle est justement d'effacer tout le SSD y compris les cellules qui ne sont pas visible par l'OS.
    D'ailleurs le "formatage complet" de windows et la "sauvegarde sécurisé" de MacOS/X sont des aberrations avec les SSD : tous les deux demandent l'écriture de données dans le but d'écraser les précédentes alors que le SSD risque d'écrire ailleurs. On se retrouve à griller quelques cycles d'écritures sans être sur d'avoir effacé quoi que ce soit.
    2