SSD : qu'est-ce que le TRIM et comment l'activer ?

Anthony Nelzin-Santos |

Alors que certains SSD triment comme des brutes, d’autres ne triment pas du tout, et cela finit par se voir. Non, ce n’est pas une blague. La commande TRIM facilite la gestion des données enregistrées dans les puces de mémoire, et participe au maintien des performances dans le temps, un aspect d’autant plus important sur les modèles les plus rapides, qui sont rarement les moins chers. Comment fonctionne-t-elle ? Faut-il absolument l’utiliser ? Suivez le guide !

Deux SSD LaCie. Image MacGeneration.

Pourquoi a-t-on besoin de la commande TRIM ?

Pour comprendre l’intérêt de la commande TRIM, il faut revenir aux bases de l’organisation des données. L’espace de stockage d’un SSD est composé de blocs, qui renferment des pages, elles-mêmes constituées de cellules de mémoire NAND formées de MOSFETs. Un bloc contient généralement de 256 Ko à 4 Mo de données, selon qu’il comprenne 128 ou 256 pages, dont la taille peut varier entre 2 et 16 Ko selon les modèles.

La structure (très simplifiée) d’un bloc. Image MacGeneration.

Vous pouvez voir un bloc comme un livre : vous pouvez lire en tournant les pages, et même écrire dans les marges restées vierges, mais vous ne pouvez pas retirer une page sans causer de dégâts. Alors que la surface d’un disque magnétique peut être (ré)écrite à l’envi, il faut trouver une page blanche pour écrire des données sur un SSD.

On ne peut pas modifier une page directement : il faut écrire les modifications sur une page blanche, puis marquer l’ancienne page comme obsolète. Image MacGeneration.
avatar Furious Angel | 

Le trim c’est comme un métru mais dans la rue

avatar DrMabuse | 

@Furious Angel

+1

avatar Bruno de Malaisie | 

@Furious Angel

Très drôle!!!!

avatar abalem | 

@Furious Angel

J’ai toujours pas pigé 😶

avatar DahuLArthropode | 

@abalem

Tram

avatar Eratic | 

Article vraiment très intéressant.

@Furious Angel : je ne sais pas si c’est la fatigue mais je n’avais rien compris au départ. Et puis finalement, j’adore ! 😂

avatar Bounty23 | 

Du coup je ne comprends pas… « mieux vaut l’utiliser si vous le pouvez » mais plus haut il est dit :

« Vous allez maintenant être confronté à un deuxième problème, le protocole UAS de la norme USB 3.0, qui permet d’accélérer les transferts de données en utilisant des commandes SCSI. TRIM est une commande ATA, mais la spécification SCSI dispose d’un équivalent direct, Unmap. »

Du coup TRIM est plus important que de conserver UAS (c’est quoi, quel intérêt?)

avatar dandu | 
On conserve l'UAS. macOS envoie la commande Unmap qui est fonctionnellement équivalente. Mais sans UAS, ça ne fonctionne pas (donc il faut un adaptateur pas trop vieux). Et il faut que le contrôleur du boîtier accepte la commande Unmap en UAS (c'est pas généralisé).
avatar Lightman | 

Cet article tombe au poil mais…

"Sans la commande TRIM, le ramasse-miette est susceptible de recopier des pages contenant des données inutiles."

Pourquoi déplace-t-il des pages ? Qui lui a demandé de le faire ? L'OS ? De lui même pour défragmenter ? Dois-je comprendre qu'il ne peux pas vérifier l'obsolescence des données dans le catalogue ?
Bon d'accord mais dans ce cas-là, ça veut dire que sans TRIM le SSD se remplit, se remplit, se remplit sans pouvoir libérer quoi que ce soit car il n'a pas moyen de se rendre compte que quelque chose est obsolète ? Ce n'est pas logique !? Alors pas compris 😤

avatar dandu | 
L'explication simple : la gestion de l'usure, son but est d'unifier l'usure. Le contrôleur va essayer de garder une usure uniforme, donc quand on écrit une donnée, il va chercher les cellules les moins usées qui sont libres pour écrire les données. Sans TRIM, le truc, c'est que ça marche tant qu'on n'a pas encore écrit toutes les cellules du SSD. Une fois qu'on a écrit chaque cellule une fois, le contrôleur il ne peut pas deviner si c'est effacé ou pas au niveau du système de fichiers. Donc il va chercher le bloc le moins usé pour mettre les nouvelles données (et déplacer des données). Avec le TRIM, il va chercher le bloc le moins usé libre (et donc probablement rien déplacer)
avatar Lightman | 

@dandu

"[sans le TRIM] il va chercher le bloc le moins usé pour mettre les nouvelles données (et déplacer des données)."

Pour les nouvelles donner OK mais déplacer les données heu… le mieux serait encore de ne rien déplacer du tout (1 écriture de moins). Mais bref, c'est sûrement bien géré.

Merci de ta réponse.

avatar Phiphi | 

@Lightman

Oui mais en pratique tu ne peux pas modifier quoi que ce soit sans le déplacer.
Donc si une page est libre (Grace a trim) : copie de la page en zone tampon - modif - collage de la page modifiée en zone libre - liberation de la page initiale (- et de temps en temps effacements de blocs, si possible très libres, et mettant ailleurs ce qui était encore utile)
Si plus rien n’est libre (et rien ne l’est plus jamais officiellement sans trim au bout d’un certain temps) : copie d’un bloc entier en zone tampon - effacement total de ce bloc - modification de la page à modifier en zone tampon - écriture du bloc modifié en totalité à l’endroit qu’on vient d’effacer.
Imagine une mémoire flash d’un seul bloc (comme sur un Psion il y a longtemps si tu as connu), sans trim, dès qu’elle est pleine, tu passes ton temps à copier la mémoire flash entièrement en mémoire vive, à la flasher, puis à la charger à nouveau. Avec trim, quand elle est pleine, tu ne copie en mémoire vive que les pages occupées, tu flashe tout, et tu ne recharges que les quelques pages utiles. Tu repars donc pour un cycle pendant lequel tu ne vas pas flasher pendant presque aussi longtemps que quand tu as mis ta mémoire neuve en service.

avatar dandu | 
Mais ce n'est pas possible, justement, sans TRIM : à partir d'un certain point, pour le contrôleur du SSD, il y a des données sur toutes les cellules. Donc il *doit* déplacer. Plus le fait que le but est d'avoir une usure uniforme. Techniquement, on pourrait évidemment réécrire au même endroit quand un fichier est modifié, mais ça implique d'utiliser les mêmes cellules, ce qui augmente l'usure. Pour l'utilisateur (et la durée de vie), c'est plus efficace d'uniformiser l'usure.
avatar Lightman | 

@dandu

sans TRIM : à partir d'un certain point, pour le contrôleur du SSD, il y a des données sur toutes les cellules. Donc il doit déplacer.

Ben, il ne peut pas déplacer puisque pour lui le SSD est plein. Les déplacer où ? Il remonte une erreur "disque plein" et c'est terminé.

Plus le fait que le but est d'avoir une usure uniforme.

Uniforme oui mais le but est d'utiliser le moins possible les cellules, pas d'user les voisines dans le seul but de les faire vieillir. Déplacer uniquement pour user plus est stupide !
Après il y a peut-être un rafraichissement à faire de temps en temps mais c'est une autre histoire.

avatar sebasto72 | 

@Lightman

« Ben, il ne peut pas déplacer puisque pour lui le SSD est plein. Les déplacer où ? Il remonte une erreur "disque plein" et c'est terminé. »

Ce n’est pas le support (SSD ou HDD) qui remonte une erreur disque plein, c’est le système de fichiers, avant même tout écriture sur le support.

Quand on dit que tous les blocs du ssd sont pleins, c’est du point de vue du ssd. Le système de fichiers sait, lui, quelles sont les pages (note la différence avec les blocs) libérées (même si physiquement il y a des données, elles ne sont plus utiles pour le système de fichiers).

Donc quand le système de fichiers demande au ssd de mettre à jour la page x, le ssd va recopier toutes les pages du bloc contenant la page x, les recopier en même temps que le nouveau contenu de la page x dans un autre bloc, et libérer l’ancien bloc entier.

En théorie, il suffit d’un bloc tampon dans le contrôleur pour que ça marche. Dans la pratique, les SSD ont plus d’espace qu’affiché, pour augmenter performances et longévité.

avatar sebasto72 | 

@Lightman

« Uniforme oui mais le but est d'utiliser le moins possible les cellules, pas d'user les voisines dans le seul but de les faire vieillir. Déplacer uniquement pour user plus est stupide ! »

Pas dans le _seul_ but de les faire vieillir, évidemment :) mais dès que le système de fichiers doit mettre à jour une page, le SSD doit ré-écrire tout le bloc ailleurs (c’est comme ça, il ne peut pas faire autrement). Il faut donc choisir le « ailleurs » au mieux pour répartir l’usure. Un algo simple est « choisis le moins usé ».

avatar Lightman | 

Une autre interrogation que cet article me donne l'occasion d'aborder car jusqu'à présent je n'est pas franchi le pas du SSD. La confidentialité des données.
L'article nous indique que les pages ne sont pas vraiment effacées mais juste marqués comme obsolètes. Rien de surprenant, c'est comme les DD. Oui mais sur les DD on peut faire un effacement sécurisé sélectif, effacement de l'espace libre ou bien un formatage bas niveau pour cela. Quid des SSD ?

On va me dire que les données sont cryptées/chiffrées donc illisibles. Alors je ne vous parle pas d'yeux indiscrets en cas de vol du SSD, non, je parle de cacher de manière définitive toute donnée sensible pour… moi-même, une personne qui viendrait à avoir le code d'une session suite à une faille, une intrusion ou une perquisition numérique par ex.

Comment fait-on sur un SSD ? Est-ce seulement possible ???

avatar raoolito | 

@Lightman

En tous cas l'effacement sécurisé est bien dispo avec les ssd sous macos

avatar Lightman | 

@raoolito

Merci de confirmer que ça existe toujours même si Apple l'a désactivé comme fonctionnalité (ligne de commande obligatoire).
Mais j'ai vu des trucs contradictoires là-dessus :
– à ne pas utiliser car use le SSD prématurément (OK),
– rendu inutile avec un SSD (pourquoi ? ),
– commande ignorée par l'OS.

Je ne sais même pas si cette commande déclenche une action véritable sur un SSD, et laquelle ?

@macomaniac es-tu là ? A l'aide 😱

avatar dandu | 
Ca va dépendre un peu des cas. Sur un vieux SSD non chiffré matériellement (et non chiffré logiciellement), oui, on peut essayer de relire les données des puces en les mettant dans un lecteur adapté. Mais en pratique, les données ne sont pas "dans l'ordre" dans les cellules, donc c'est... compliqué. Sur un SSD chiffré matériellement, la majorité des modèles modernes, ça n'a aucun intérêt : on peut essayer de lire les données de la mémoire, mais elles sont chiffrées, donc inutilisables (sauf à avoir la clé, forcément). Idem s'il est chiffré au niveau de l'OS. Et même dans le cas ou une personne a accès à l'ordinateur allumé, les données effacées au niveau du système de fichiers ne sont pas accessibles de façon triviale (en tout cas pas sans le mot de passe de l'utilisateur, déjà). Et si le TRIM est activé (ce qui est le cas sur un SSD interne dans un Mac), c'est des 0. Sur le coup, avec ce genre d'interrogations, un disque dur est plus vulnérable par défaut, dans le sens ou c'est rarement chiffré, et que les données sont quand même habituellement contigüe (sauf disque très fragmenté) avec une corresspondance entre la position dans le système de fichiers et sur le disque (ce qui est absolument pas le cas des SSD).
avatar Lightman | 

@dandu

Merci de ton éclairage.

avatar koko256 | 

@dandu

"Sur un SSD chiffré matériellement, la majorité des modèles modernes, ça n'a aucun intérêt : on peut essayer de lire les données de la mémoire, mais elles sont chiffrées, donc inutilisables (sauf à avoir la clé, forcément)."
Et où est la clé dans le cas d'un chiffrement par le disque lui-même ?

avatar dandu | 
Ca dépend des cas. Normalement, c'est lié à l'ordinateur, par exemple dans l'UEFI. Dans certains cas, la clé est sur le SSD lui-même (ce qui est complètement idiot, mais ça a des avantages pratiques, comme l'usage en externe). Et en théorie, dans les deux cas, elle est évidemment inaccessibles.
avatar raoolito | 

Merci anthony !
Les commentaires en ont parlé, macG l'a fait :)

avatar Paul Position | 

Choses promises, choses dues !
Bravo, et merci.
L'article m'a rassuré sur l'usage de SSD sans trim avec un formatage APFS.

avatar dandu | 
D'ailleurs, il manque un truc (très) relou : la gestion du cache SLC. Certains SSD utilisent le cache SLC de façon dynamique : au lieu de réserver une partie de la mémoire (petite) pour le cache SLC en question, ils utilisent l'espace libre. Donc si on a un SSD en TLC qui a (imaginons) 300 Go de libre, on a 100 Go de cache SLC (je schématise un peu). Le contrôleur écrit en mode SLC puis - plus tard, en arrière plan - il réécrit en mode TLC. Mais cette astuce (efficace), elle dépend du TRIM. Parce que sans TRIM, le contrôleur ne connaît pas l'espace libre disponible comme cache. C'est extrêmement visible sur les SSD externes sans TRIM : le cache fonctionne au déballage, mais quand on a écrit une fois entièrement la capacité du SSD, il ne fonctionne plus du tout. Donc on teste au déballage, c'est rapide, et après quelques jours/semaines (en fonction de l'usage), on se retrouve avec un SSD qui écrit (beaucoup) plus lentement. Et sans solution simple à part activer le TRIM.
avatar N01R | 

Bonjour à tous,
Et sur une partition NTFS on a besoin du TRIM aussi du coup non? On l’active comment dans ce cas sous Bootcamp/Windows ? C’est pour un de mes disques SSD externes, ça m’intéresse :)
Merci à vous :)

avatar raoolito | 

@N01R

trim = os
donc l'os doit etre capable de lire et ecrire sur la partoche donc ya que windows qui le peut avec le ntfs

avatar dandu | 
Ben oui. Sous Windows, c'est normalement activé par défaut depuis Windows 7. En USB, depuis Windows 10, avec les mêmes contraintes que macOS : faut un adaptateur compatible quand même.
avatar YetiJS93 | 

Merci pour l’article !

Quid de l’utilisation d’un SSD (exclusivement) sur iPadOS ?
La fonction TRIM est-elle activée/activable?

avatar raoolito | 

@YetiJS93

ah oui tiens ?
ios gere-t-il le trim ?

avatar apaisant | 

Un article commencé sous la douche Anthony?

avatar Anthony Nelzin-Santos | 
@apaisant : toujours.
avatar BlanBlan | 

Donc avec un gros SSD (j'ai un 2TO sur mon MacBook Pro 16'' M1) il sera moins vite usé qu'un petite capacité de 512 GB par exemple ?

avatar dandu | 
Oui. A technologie identique on gagne forcément en usure en augmentant la capacité : y a plus de cellules, et donc d'écriture possible. Après, ça va aussi dépendre de la technologie : les grandes capacités tendent à utiliser de la mémoire plus dense, donc moins durable. Sur les SSD de 8 To, Samsung utilise par exemple de la mémoire QLC (4 bits), moins endurante que la 3 bits utilisée dans d'autres modèles. Apple, j'en ai aucune idée, mais vu le prix/ce que la marque fait d'habitude, c'est probablement de la TLC (3 bits)
avatar BlanBlan | 

@dandu

Merci de l'information !
Super article en tout cas !

avatar Mac1978 | 

Merci pour l’article très claire et complet.

Dès ce soir, je vais vérifier si le SanDisk Extreme Pro acquis hier trime déjà ou si je dois le motiver.

avatar Scaterbrain | 

@Mac1978

Alors est ce que cela a fonctionné de ton côté sur ce ssd ?:) 🙏

CONNEXION UTILISATEUR