Après avoir passé en revue les différents contrôleurs disponibles sur le marché, intéressons-nous à un autre problème des SSD, la perte de performance.
Après avoir passé en revue les différents contrôleurs disponibles sur le marché, intéressons-nous à un autre problème des SSD, la perte de performances, et aux moyens qui existent pour régler ce problème.
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 Wear Leveling 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 modèles récents utilisés de façon intensive, est due aux algorithmes : le SSD, quand on va écrire un fichier, va cherche la puce de mémoire la plus apte à recevoir une écriture, 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. Et comme à partir d'un certain moment, toutes les cellules d'un SSD ont été utilisées au moins une fois, le SSD va donc devoir interroger le système pour vérifier si une cellule est vide. Ce qui peut, en cas de SSD très utilisé, poser des problèmes de performances : le SSD va choisir une cellule X, il va interroger le système d'exploitation, qui va lui dire si elle est utilisée ou pas, dans le premier cas, le SSD va utiliser une cellule Y et demander au système, etc. Si le SSD a été rempli puis que les données ont été supprimées par le système, le SSD va donc chercher au hasard, alors qu'il pourrait simplement écrire directement dans un endroit « supprimé », mais il ne peut pas deviner où se trouvent les données supprimées.
Le TRIM
La solution la plus évidente, elle vient de la norme ATA8, et elle est intégrée à Windows 7. 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 dans le système de Microsoft et uniquement avec un firmware compatible (uniquement pour les SSD à base d'Indilinx Barefoot). Concrètement, le TRIM consiste à effacer physiquement les données au moment de la suppression, contrairement à la technique habituelle qui consiste à marquer les données supprimées sans les effacer réellement. Avec le TRIM, le SSD est capable de voir où sont les données effacées et donc évite de chercher à les trouver. Petit défaut de la technologie, les effacements sont physiques, ce qui ralentit un peu la suppression de fichiers, mais les performances dans le temps devraient rester stables. Actuellement, le TRIM est rare, mais Intel devrait proposer un firmware compatible rapidement, tout comme Samsung (même si la politique de ce dernier pose des problèmes, les mises à jour étant réservées aux OEM). Reste le plus gros problème : il faut que le système d'exploitation (ou tout du moins le pilote qui gère le système de fichier) soit compatible, et seul Windows 7 l'est actuellement, en NTFS.
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.
Terminons par rappeler que tous les SSD ne sont pas touchés par le problème (ou, tout du moins, dans une moindre mesure) et que la solution la plus efficace actuellement est le TRIM, même si elle impose un temps d'effacement plus élevé (sans que ce soit, a priori, dramatique).