trim (informatique)

Le but de cette instruction est de maintenir la vitesse du SSD tout au long de sa durée d'utilisation, évitant le ralentissement que les premiers modèles manifestaient une fois que toutes les cellules avaient été écrites au moins une fois.

Des outils permettant la remise à l'état initial étaient certes disponibles pour certaines unités, mais ceux-ci en effaçaient l'intégralité des données, ce qui rendait leur utilisation difficilement praticable en tant qu'optimisation régulière.

Les unités SSD ne savent pas quels blocs sont réellement utilisés et quels blocs sont libres, car elles ne sont pas informées des structures du système de fichier utilisé. Les clusters inutilisés sont donc inconnus du support (les données sont présentes sur le support, mais ne sont plus utilisées par le système d'exploitation, par exemple une corbeille vidée). Voici pourquoi :

1. Les SSD peuvent écrire des blocs de 4 ko, mais pour des raisons matérielles, ils doivent effacer des blocs plus larges (par exemple 128 ou 512 ko)[1]. Le système de fichiers de l'ordinateur connaît les blocs utilisés, et peut en déduire les blocs inutilisés, mais l'unité de contrôle du SSD - qui ne sait pas à priori quelle organisation utilise ce système (ext4, exFAT, NTFS ou une dizaine d'autres) ignore de ce fait quels sont les blocs de 4 ko toujours en cours d’utilisation s’ils ont été écrits précédemment, où sont les tables d'allocation et comment elles sont organisées. Chaque écriture demandera un cycle lecture-effacement-modification-écriture portant sur une zone plus vaste, dans le cas où il n'y a plus d’autres blocs libres sur le SSD (c'est-à-dire après que tous les blocs ont été partiellement remplis). Ce phénomène est appelé amplification d’écriture (« write amplification »).
2. La répartition de l’usure (« wear levelling ») permet à une unité de réarranger ses données pour que les écritures ne soient pas concentrées de façon hétérogène sur la carte flash. Les cellules flash tolèrent quelques dizaines de milliers d’écritures avant de devenir inopérantes, d'où l'intérêt de répartir l'usure afin d'optimiser la longévité globale du support. Certains contrôleurs SSD déplacent donc les données sur toute l’unité pour exercer l'usure de façon égale sur tous les blocs. Si l’unité ne sait pas quels blocs sont réellement utilisés par le système de fichiers, chaque bloc de données écrit sur l’unité demande une écriture additionnelle due au déplacement du bloc.

La commande trim a été introduite pour permettre de purger complètement les données officiellement effacées. La récupération de données devient donc impossible (ce qui sera un avantage ou un inconvénient suivant le contexte).

La spécification de la commande trim est standardisée en tant que partie du standard d’interface AT Attachment (ATA), mené par le Comité Technique T13 de l’International Commitee for Information Technology Standards.

Premier passage de trimcheck : des données sont mises en place, puis (du point de vue du système d'exploitation) effacées.

Second passage de trimcheck : on voit que l'information ne se trouve plus dans les clusters : le disque a donc bien été informé de l'effacement par le système d'exploitation.

Le SSD doit supporter le trim. Les anciens modèles devront recevoir une mise à jour de leur firmware, faute de quoi cette commande sera ignorée.

Il faut aussi un contrôleur ATA gérant le 48-bit LBA addressing et dont le pilote supporte le trim. En général c'est le cas des contrôleurs Serial ATA supportant la norme AHCI.

Dans le cas d'une connexion en SSD externe par USB (USB3 en général), on peut tester si le TRIM est correctement géré ou non par l'utilitaire gratuit trimcheck[2], qui doit cependant être installé sur le SSD lui-même.

• Microsoft Windows : trim a été implémenté dans Windows 7 et Windows Server 2008 R2, et livré avec la version finale de ces systèmes d’exploitation en octobre 2009.
• Linux :
  • S'agissant du système de fichiers ext4 : la fonction trim (méthode dite on-the-fly trim, online discard ou encore realtime discard) a été intégrée dans la version 2.6.33 du noyau (à noter, d'une part, que la fonction doit être activée manuellement en ajoutant l'option « discard » dans le fichier fstab, et, d'autre part, que certaines distributions ont rétroporté la fonction dans un noyau plus ancien)
  • la version 6 « Squeeze » de Debian dispose d'une version du noyau 2.6.32 gérant le trim dans les dépôts officiels Backports) ;
  • La version 2.6.37 du noyau ajoute la fonction fitrip (méthode dite batch discard) pour ext4 qui permet de différer l'exécution de commandes trim en vue de les traiter d'un coup (cette fonction est réalisée par le programme fstrim qui dépend de la suite util-linux version 2.19 ou supérieure)[3].

Note : S'agissant du système de fichiers Btrfs : le online discard est géré depuis la version 2.6.32 du noyau, et le batch discard est géré depuis la version 2.6.39.

• macOS : la commande trim a été implémentée à partir de la version 10.6.6 d'OS X (Snow Leopard) en février 2011, mais le système est par défaut limité aux seuls SSD installés par Apple[4]. Il est possible d'activer le trim sur d'autres marques de SSD à l'aide d'utilitaires forçant la commande sur tout type de SSD. Une commande officielle sudo trimforce enable a été ajoutée depuis OS X 10.10.4 pour activer le trim sur un SSD non Apple.

Là où trim n’est pas automatiquement supporté par le système d’exploitation, il existe des utilitaires envoyant des commandes trim manuellement. Typiquement, ils listent tous les blocs libres spécifiés comme tel par le système d’exploitation et passent ensuite cette liste sous la forme d’une série de commandes trim à l’unité. Ces utilitaires sont disponibles chez différents fabricants (Intel, XtremeSystems) mais il existe également des outils génériques comme hdparm (depuis sa version 9.17).

• Mémoire flash
• Solid-state drive, ces unités de stockage basées sur de la mémoire flash
• Répartition de l'usure (wear levelling)
• hdparm