Pourquoi les SSD ont besoin de la commande TRIM, Réactions à la publication du 31/10/2014

[Lionel]

Malgré les très nombreuses explications apportées sur la commande TRIM, essentielle pour les SSD, certains lecteurs continuent à nous interroger sur son intérêt. Nous allons donc essayer de l'expliquer une fois encore de la manière la plus simple possible.
Commençons donc par rappeler le fonctionnement de la commande qui efface des données sur un disque dur. Elle est très simple. Elle ne va pas aller réellement effacer les données écrites mais seulement aller dans le catalogue du disque dur, un volumineux fichier placé au début du disque, et effacer les entrées pointant vers le fichier. Ainsi, le système et le disque sauront que les secteurs ayant contenu ces données sont considérés comme libres et peuvent être réécrits.
Pour des raisons de compatibilité, les SSD ont adopté le même fonctionnement que les disques durs. Il y a donc un catalogue et des secteurs qui dans ce cas sont des cellules de mémoire Flash. Quand des données sont effacées du SSD, le système fait la même chose, effacer l'entrée et ainsi le système pourra réécrire à ces emplacements.
Seulement, les SSD ont une grosse différence fondamentale. Avant d'écrire des données sur une cellule il est nécessaire de passer par une phase d'effacement (ce qui n'est pas le cas avec un disque dur). Ainsi, si les cellules contiennent encore des données, ce qui est le cas avec l'effacement de base, il faudra d'abord les préparer à recevoir du contenu avant de le mettre dedans. C'est la raison pour laquelle les performances des SSD en écriture se dégradent alors.

La commande TRIM est là pour pallier ce problème. Elle va permettre au contrôleur du SSD de savoir que des cellules ne sont plus utilisées et il va les préparer à la réécriture au moment de l'effacement. Ainsi, si l'effacement sera plus long (dans les faits on ne s'en aperçoit pas), la réécriture se fera sans aucune perte de temps et les performances seront conservées.

Certes, il existe d'autres techniques destinées à assurer un fonctionnement optimal d'un SSD, dont le Garbage Collector souvent cité. Il permet au SSD de s'optimiser durant les temps morts où il est peu ou pas sollicité. Mais cela ne fait pas de miracles et ne remplace pas le TRIM, c'est juste une optimisation en tâche de fond que l'on pourrait de loin assimiler à une défragmentation.
Lien vers le billet original

[JC]

Bonsoir,

Merci !

On ne peut faire plus pédagogique et concis.

Bonne nuit à tous

NB: j'ose me permettre une minuscule remarque de syntaxe, cher Lionel, concernant l'usage du verbe pallier...

Ce message a été modifié par JC - 31 Oct 2014, 00:09.

[iAPX]

Comme indiqué dans l'autre sujet, avec 4ans d'usage d'un Crucial C300 256GB, sans TRIM évidemment, il reste toujours réactif et très agréable dans deux MacBook Pro 17" puis maintenant dans le MacBook d'un ami.

Il ne faut pas vraiment exagérer: les performances sous AJA seront différentes (très), alors qu'en usage quotidien ça sera rapide voire d'après mon ami "On dirait un ordinateur neuf" (il utilise un MacBook Core™2 Duo 2GHz 2007! lol). Et oui c'est rapide au quotidien, même avec une très vieille génération de SSD et des algorithmes bien moins performants qu'aujourd'hui.

Alors oui les tests (notamment AJA) montreront une différence importante. Mais l'usage au quotidien, même sur un Quad-Core, donnera une toute autre importance à la capacité à lire dans une charge mixte (aléatoires+séquantiels en parallèle, mixé avec quelques écritures).
Évidemment si votre journée consiste à copier des folder fils d'un endroit à l'autre du SSD, comme le font les benchmarks, vous verrez la différence. Dans ce cas je préconise une autre activité, comme du vrai travail

[dandu]

Joli, dommage que ça ne fonctionne pas comme ça.

Les données ne doivent pas être effacées nécessairement sur de la mémoire flash, c'est juste une question d'usure.

En gros, en usage normal (sans TRIM), le contrôleur du SSD va essayer de garder une usure constante et donc de trouver des cellules vides. S'il n'y en a pas, il va chercher des cellules peu usées et peu utilisées, déplacer les données qu'il y a dessus et écrire les nouvelles données. On aura donc physiquement deux écritures, une pour le déplacement et une pour l'écriture elle-même.

Le principal problème de cette technique, c'est que le contrôleur ne sait pas ce que contient une cellule : ça peut être un fichier de l'OS mais aussi un truc effacé, vu que — comme l'explique bien Lionel — on efface juste l'entrée.

Le but du TRIM est simplement d'indiquer au SSD qu'une cellule est bien vide quand on efface un fichier, c'est juste un flag : le SSD sait que la cellule est vide d'un point de vue logique et écrit dessus directement. Du coup, on aura plus de cellules vides à disposition et donc on évitera la phase de réécriture.


Avec ce qu'explique Lionel, on verrait un temps d'effacement bien plus élevé en activant le TRIM, hors ce n'est pas le cas : c'est un peu plus lent que quand il n'est pas activé (on doit "flagger" un tas de cellule) mais ce n'est pas énorme.

[zero]

Dandu a raison, la fonction Trim sert juste à éviter des réecrites superflues afin de préserver l'usure du SDD parce que le contrôleur ne connait pas l'emplacement des fichiers éffacés ou pas. Sans Trim, le contrôleur (Garbage Collector et autres) manipule les cellules des fichiers effacés sans distinction.
Le fait que le contrôleur n'ai plus à manipuler les cellules des fichiers effacées fait gagner aussi un peu de temps.

Ce message a été modifié par zero - 31 Oct 2014, 00:59.

[SartMatt]

Là je te suis pas dandu :

Les données ne doivent pas être effacées nécessairement sur de la mémoire flash, c'est juste une question d'usure.

Sur une flash clasique, il y a bien quasiment toujours besoin d'effacer avant de pouvoir réécrire. À l'état vierge, tous les bits d'un bloc sont à 1. Passer de 1 à 0 est ensuite possible unitairement (en pratique toutefois on fait les opérations par page, adresser chaque bit indépendamment serait bien trop coûteux). Mais par contre, passer de 0 à 1 ne peut se faire que sur tout le bloc d'un coup.

Donc on peut effectuer plusieurs écritures successives sur une même page sans effacement, mais uniquement tant que les nouvelles données ne nécessitent pas de faire passer un bit de 0 à 1. En pratique, je doute fort que les contrôleurs cherchent à vérifier ça pour économiser les effacement (d'autant plus que le garbage collector aura généralement anticipé les effacements), vu que ça implique de relire au préalable la page qui va être écrasée. Par contre certains contrôleurs savent travailler avec des demi pages (en faisant une écriture avec tous les bits de la première ou de la seconde demi-page à 1, ça ne modifie que l'autre demi-page).

Par contre, dans le cas du TRIM, l'effacement se fait effectivement de manière asynchrone par rapport à la commande, comme tu le dis. La page est marquée dirty, et ensuite, c'est généralement le Garbage Collector qui s'occupera des effacements, à postériori. Effacer immédiatement serait d'ailleurs contreproductif dans certains cas, du fait que les blocs d'effacement sont plus gros que les pages (si tu "trimes" le contenu d'une page, un effacement immédiat implique d'effacer tout le bloc, et donc de recopier au préalable toutes les pages non "trimées").


Je suis pas sûr non plus que les contrôleurs actuels fassent du déplacement/réécriture en dehors du Garbage Collector lors d'opérations d'écriture de l'hôte. En effet, avec l'overprovisionning, il y a toujours une bonne quantité de pages vides ou dirty, donc c'est là que les écritures vont se faire en général. Ensuite le Garbage Collector va profiter des périodes d'inactivité pour réorganiser les données, et notamment déplacer les données qui changent peu vers des cellules plus usées pour ne pas occuper les cellules les plus fraîches.

Les volumes d'écritures effectués en tâche de fond par le GC peuvent d'ailleurs être assez impressionnant... Ça fait quelques temps que je surveille régulièrement les chiffres remontées par mon MX100 via le SMART, en faisant des rafraichissement je peux voir le volume écrit par les opérations interne augmenter régulièrement alors que le volume écrit par l'hôte ne bouge pas d'un poil, et j'ai l'impression que plus le temps passe, plus ce volume des opérations internes augmente... Début juillet, j'avais 522 Go d'écritures internes au total pour 915 Go d'écritures hôte, aujourd'hui je suis à 3108 Go d'écritures internes pour 3128 Go d'écritures hôte...

[benjinthesky]

Bonjour, je viens d'installer un SSD 240go OWC Mercury dans mon imac 27 de 2009 (montage DD et SSD avec Fusion drive), sur le site OWC ils indiquent qu'il n'y a pas besoin de trim, et explique leurs technologie:

http://blog.macsales.com/21641-with-an-owc...o-need-for-trim

With An OWC SSD, There’s No Need For TRIM

Ont ils raison d'indiquer cela?

Ce message a été modifié par benjinthesky - 31 Oct 2014, 06:05.

[fudo]

Bonjour, je viens d'installer un SSD 240go OWC Mercury dans mon imac 27 de 2009 (montage DD et SSD avec Fusion drive), sur le site OWC ils indiquent qu'il n'y a pas besoin de trim, et explique leurs technologie:

http://blog.macsales.com/21641-with-an-owc...o-need-for-trim

With An OWC SSD, There’s No Need For TRIM

Ont ils raison d'indiquer cela?

Ben fait des benchs quand ton disque est vide et fais le quand ton disque a été écrit complètement au moins une fois.... je pense que tu auras des surprises.
Je pense que l'ion peut effectivement se passer de la fonction TRIM si on peut se contenter de performances degradées.

Je rajouterai que bcp de monde dont moi le 1er achetent des SSD pour leur machines mais a cause de la garantie ou pour éviter de demonter la bête se contente de les brancher en USB3 ou Firewire 800. Or la fonction TRIM est une fonctionnalité inhérente à l'interface ATA, donc tous les disques branchés via des boitiers externes fonctionnent de façon dégradés... j'ignore le cas du thunderbolt.. il s'agit de lien PCI Express il me semble.. donc pas d'espoir... seul a priori le e-sata trouverait grace.
Sans parler du fait qu'Apple bloque souvent la possibilité de mettre un disque non Apple. J'ai cru lire qu'un fabricant avait carrément proposer des disques dont l'ID vendor était Apple pour assurer une compatibilité pleine...

Ce message a été modifié par fudo - 31 Oct 2014, 07:59.

[SartMatt]

Or la fonction TRIM est une fonctionnalité inhérente à l'interface ATA, donc tous les disques branchés via des boitiers externes fonctionnent de façon dégradés... j'ignore le cas du thunderbolt.. il s'agit de lien PCI Express il me semble.. donc pas d'espoir... seul a priori le e-sata trouverait grace.

En TB, ça marche : l'OS voit bien le SSD comme un périphérique ATA et peut lui envoyer n'importe quelle commande ATA.

With An OWC SSD, There’s No Need For TRIM

Ont ils raison d'indiquer cela?

Beaucoup de marketing là dedans... Les tests montrent que les contrôleurs SandForce (sur l'Intel 520 par exemple) n'échappent pas à la chute de performances : http://www.hardware.fr/articles/906-16/ten...rformances.html

[Licorne31]

(...)Commençons donc par rappeler le fonctionnement de la commande qui efface des données sur un disque dur. Elle est très simple. Elle ne va pas aller réellement effacer les données écrites mais seulement aller dans le catalogue du disque dur, un volumineux fichier placé au début du disque, et effacer les entrées pointant vers le fichier. Ainsi, le système et le disque sauront que les secteurs ayant contenu ces données sont considérées comme libres et peuvent être réécrites.
Pour des raisons de compatibilité les SSD ont adopté le même fonctionnement que les disques durs. Il y a donc un catalogue et des secteurs qui dans ce cas sont des cellules de mémoire Flash. Quand des données sont effacées du SSD, le système fait la même chose, effacer l'entrée et ainsi le système pourra réécrire à ces emplacements.
Seulement, les SSD ont une grosse différence fondamentales. Avant d'écrire des données sur une cellule il est nécessaire de passer par une phase d'effacement (ce qui n'est pas le cas avec un disque dur). Ainsi, si les cellules contiennent encore des données, ce qui est le cas avec l'effacement de base, il faudra d'abord les préparer à recevoir du contenu avant de le mettre dedans. C'est la raison pour laquelle les performances des SSD en écriture se dégradent alors.
(...)

Question de candide, ne serait-il pas possible pour un firmware de SSD d'intégrer directement le TRIM, c'est à dire, en tâche de fond (comme le GC), de scanner les cellules déclarées libres dans le catalogue, et de les effacer (mise à 1) si elles ne le sont pas déja? Ou, mieux, de les effacer (mise à 1) au moment où elles sont libérées du catalogue (c'est à dire quand l'OS les efface)?

D'accord, ça ralentirait un peu le SSD... Mais vu les performances, échanger un peu de rapidité en vitesse de pointe contre beaucoup de rapidité en vitesse de croisière, et de fiabilité sur le long terme, ça se tient, non?

[ob1]

Est-ce que ce raisonnement s'applique aussi aux cartes Compact Flash (CF) montées sur un adaptateur IDE/CF ?
En d'autres termes, est-ce que les cartes CF ont besoin de la commande TRIM ?

Est-ce qu'un formatage permet de récupérer toutes les cellules des CF/SSD ?

(oui, je sais, ça fait beaucoup de questions pour un vendredi matin)

[rotche]

Une petite question sur la commande Trim. J ai lu plusieurs fois ici qu elle n est pas compatible avec les controleurs Raid. Qu en est il du Raid logiciel apple integre a mac OSX?

[tenets]

J'ai un MacBook de 2010 avec le SSD d'origine,(128 Go).
J'utilise toujours la fonction "vider la corbeille en mode sécurisé", qui efface les données et pas seulement leur adresse.
Est-ce que ça peut faire le même effet que la fonction TRIM ?
Si ça ne le fait pas, est-ce que ça "use" inutilement les cellules?
Merci d'avance.

[SartMatt]

Question de candide, ne serait-il pas possible pour un firmware de SSD d'intégrer directement le TRIM, c'est à dire, en tâche de fond (comme le GC), de scanner les cellules déclarées libres dans le catalogue, et de les effacer (mise à 1) si elles ne le sont pas déja? Ou, mieux, de les effacer (mise à 1) au moment où elles sont libérées du catalogue (c'est à dire quand l'OS les efface)?

C'est justement le TRIM qui permet au contrôleur de cataloguer les cellules libres.

Pour faire la même chose sans le TRIM, il faudrait que le SSD soit capable de comprendre la structure logique des données stockées dessus (table des partitions, système de fichiers...) pour analyser ça et détecter les emplacements qui ne sont plus utilisés. Ce serait beaucoup trop complexe à mettre en place, trop risqué (risque de supprimer des données par erreur...). Et pour les Mac, ça n'améliorerait sans doute pas les choses : ça supporterait sans doute le NTFS, éventuellement l'exFAT et le FAT32, mais je doute que les constructeurs s'emmerderaient aussi avec le HFS...

En d'autres termes, est-ce que les cartes CF ont besoin de la commande TRIM ?

La commande TRIM peut être bénéfique pour tout support basé sur de la mémoire flash.

Par contre, je ne sais pas si les cartes CF supportent la commande TRIM... J'en doute, vu qu'elles reposent à priori sur une version plus ancienne du protocole ATA.

Est-ce qu'un formatage permet de récupérer toutes les cellules des CF/SSD ?

Non, un formatage simple ne permet pas d'indiquer au contrôleur que les cellules ne contiennent plus de données valides.
Un effacement avec la commande Secure Erase le permet sur les SSD, mais je ne sais pas si les cartes CF supportent cette commande.

J'utilise toujours la fonction "vider la corbeille en mode sécurisé", qui efface les données et pas seulement leur adresse.
Est-ce que ça peut faire le même effet que la fonction TRIM ?
Si ça ne le fait pas, est-ce que ça "use" inutilement les cellules?

Non, ça ne fait pas la même chose que le TRIM. L'effacement sécurisé de la corbeille, ça écrase les données du fichier au lieu de simplement supprimer son enregistrement dans le système de fichiers.
Mais pour le contrôleur du SSD, ces données qui ont servi à écraser le fichier sont toujours des données valides.

Et oui, l'utilisation de cette commande induit de l'usure supplémentaire, puisque ça réécrit au moins une fois les fichiers.

[Licorne31]

Question de candide, ne serait-il pas possible pour un firmware de SSD d'intégrer directement le TRIM, c'est à dire, en tâche de fond (comme le GC), de scanner les cellules déclarées libres dans le catalogue, et de les effacer (mise à 1) si elles ne le sont pas déja? Ou, mieux, de les effacer (mise à 1) au moment où elles sont libérées du catalogue (c'est à dire quand l'OS les efface)?

C'est justement le TRIM qui permet au contrôleur de cataloguer les cellules libres.

Pour faire la même chose sans le TRIM, il faudrait que le SSD soit capable de comprendre la structure logique des données stockées dessus (table des partitions, système de fichiers...) pour analyser ça et détecter les emplacements qui ne sont plus utilisés. Ce serait beaucoup trop complexe à mettre en place, trop risqué (risque de supprimer des données par erreur...). Et pour les Mac, ça n'améliorerait sans doute pas les choses : ça supporterait sans doute le NTFS, éventuellement l'exFAT et le FAT32, mais je doute que les constructeurs s'emmerderaient aussi avec le HFS...

Toujours candide, est-ce que le FW du SSD ne pourrait pas s'envoyer à lui-même une commande "trim" chaque fois que l'OS lui déclare qu'un fichier est effacé?

[SartMatt]

Toujours candide, est-ce que le FW du SSD ne pourrait pas s'envoyer à lui-même une commande "trim" chaque fois que l'OS lui déclare qu'un fichier est effacé?

L'OS ne déclare pas au SSD qu'un fichier est effacé. Le SSD ne connait pas les fichiers.

Pour lui il y a simplement un ensemble de secteurs, qui contiennent des données ou non. Chaque secteur étant en interne au SSD mappé sur un groupe de cellules.

Quand on supprime un fichier, ce que le SSD reçoit, c'est simplement une modification du contenu de quelques secteurs (ceux où est stocké l'enregistrement du fichier dans la structure du système de fichier). Il ne peut pas savoir que en même temps ça veut dire que tels autres secteurs sont désormais inutilisés (ceux où le fichier était stocké).

C'est à ça que sert le TRIM : il donne au SSD des listes de secteurs qui ne contiennent plus de données utiles.

[dandu]

Là je te suis pas dandu :

Les données ne doivent pas être effacées nécessairement sur de la mémoire flash, c'est juste une question d'usure.

Sur une flash clasique, il y a bien quasiment toujours besoin d'effacer avant de pouvoir réécrire. À l'état vierge, tous les bits d'un bloc sont à 1. Passer de 1 à 0 est ensuite possible unitairement (en pratique toutefois on fait les opérations par page, adresser chaque bit indépendamment serait bien trop coûteux). Mais par contre, passer de 0 à 1 ne peut se faire que sur tout le bloc d'un coup.

Donc on peut effectuer plusieurs écritures successives sur une même page sans effacement, mais uniquement tant que les nouvelles données ne nécessitent pas de faire passer un bit de 0 à 1. En pratique, je doute fort que les contrôleurs cherchent à vérifier ça pour économiser les effacement (d'autant plus que le garbage collector aura généralement anticipé les effacements), vu que ça implique de relire au préalable la page qui va être écrasée. Par contre certains contrôleurs savent travailler avec des demi pages (en faisant une écriture avec tous les bits de la première ou de la seconde demi-page à 1, ça ne modifie que l'autre demi-page).

Par contre, dans le cas du TRIM, l'effacement se fait effectivement de manière asynchrone par rapport à la commande, comme tu le dis. La page est marquée dirty, et ensuite, c'est généralement le Garbage Collector qui s'occupera des effacements, à postériori. Effacer immédiatement serait d'ailleurs contreproductif dans certains cas, du fait que les blocs d'effacement sont plus gros que les pages (si tu "trimes" le contenu d'une page, un effacement immédiat implique d'effacer tout le bloc, et donc de recopier au préalable toutes les pages non "trimées").

Je suis pas sûr non plus que les contrôleurs actuels fassent du déplacement/réécriture en dehors du Garbage Collector lors d'opérations d'écriture de l'hôte. En effet, avec l'overprovisionning, il y a toujours une bonne quantité de pages vides ou dirty, donc c'est là que les écritures vont se faire en général. Ensuite le Garbage Collector va profiter des périodes d'inactivité pour réorganiser les données, et notamment déplacer les données qui changent peu vers des cellules plus usées pour ne pas occuper les cellules les plus fraîches.

Les volumes d'écritures effectués en tâche de fond par le GC peuvent d'ailleurs être assez impressionnant... Ça fait quelques temps que je surveille régulièrement les chiffres remontées par mon MX100 via le SMART, en faisant des rafraichissement je peux voir le volume écrit par les opérations interne augmenter régulièrement alors que le volume écrit par l'hôte ne bouge pas d'un poil, et j'ai l'impression que plus le temps passe, plus ce volume des opérations internes augmente... Début juillet, j'avais 522 Go d'écritures internes au total pour 915 Go d'écritures hôte, aujourd'hui je suis à 3108 Go d'écritures internes pour 3128 Go d'écritures hôte...

Ce que je voulais dire, c'est qu'il n'y a pas d'opération d'écriture spécifique pour la réécriture sans TRIM. Dans tous les cas, le contrôleur doit effacer la mémoire et réécrire, avec TRIM ou sans, mais c'est dans le fonctionnement même de la flash.

Le but du TRIM est pas d'empêcher la réécriture (elle est de toute façon là) mais d'empêcher le contrôleur de déplacer des données qui "effacées" et d'améliorer les algorithmes de la gestion de l'usure.

(...)Commençons donc par rappeler le fonctionnement de la commande qui efface des données sur un disque dur. Elle est très simple. Elle ne va pas aller réellement effacer les données écrites mais seulement aller dans le catalogue du disque dur, un volumineux fichier placé au début du disque, et effacer les entrées pointant vers le fichier. Ainsi, le système et le disque sauront que les secteurs ayant contenu ces données sont considérées comme libres et peuvent être réécrites.
Pour des raisons de compatibilité les SSD ont adopté le même fonctionnement que les disques durs. Il y a donc un catalogue et des secteurs qui dans ce cas sont des cellules de mémoire Flash. Quand des données sont effacées du SSD, le système fait la même chose, effacer l'entrée et ainsi le système pourra réécrire à ces emplacements.
Seulement, les SSD ont une grosse différence fondamentales. Avant d'écrire des données sur une cellule il est nécessaire de passer par une phase d'effacement (ce qui n'est pas le cas avec un disque dur). Ainsi, si les cellules contiennent encore des données, ce qui est le cas avec l'effacement de base, il faudra d'abord les préparer à recevoir du contenu avant de le mettre dedans. C'est la raison pour laquelle les performances des SSD en écriture se dégradent alors.
(...)

Question de candide, ne serait-il pas possible pour un firmware de SSD d'intégrer directement le TRIM, c'est à dire, en tâche de fond (comme le GC), de scanner les cellules déclarées libres dans le catalogue, et de les effacer (mise à 1) si elles ne le sont pas déja? Ou, mieux, de les effacer (mise à 1) au moment où elles sont libérées du catalogue (c'est à dire quand l'OS les efface)?

D'accord, ça ralentirait un peu le SSD... Mais vu les performances, échanger un peu de rapidité en vitesse de pointe contre beaucoup de rapidité en vitesse de croisière, et de fiabilité sur le long terme, ça se tient, non?

Certains le font, mais ça suppose que le contrôleur connaisse le système de fichiers utilisé et qu'il soit capable de détecter ce qui est effacé. A une époque, certains SSD le faisaient sur du NTFS, mais sur du HFS, faut pas rêver. Et ça implique quand même que le truc analyse les données quand tu fais rien.

Après, le TRIM est en temps réel sous Windows et OS X, mais pas sous Linux, par exemple, qui scanne régulièrement et met à jour les données. Et sous OS X, on peut le forcer en lançant une vérification du disque par exemple (sous Windows, il me semble qu'on peut juste en formattant)

[Ambroise]

Joli, dommage que ça ne fonctionne pas comme ça.

Les données ne doivent pas être effacées nécessairement sur de la mémoire flash, c'est juste une question d'usure.

Je ne connais pas trop le fonctionnement des SSD mais je connais bien celui des EEPROMs en électronique et l'explication de Lionel sur le TRIM me semble du coup parfaitement cohérente et en adéquation avec le fonctionnement des mémoires Flash (qui sont un type particulier d'EEPROM).

Une des caractéristiques des Flash c'est que les écritures ne fonctionnent que dans un sens : on peut uniquement augmenter la résistance d'une cellule, soit passer de 1 à 0. Pour remettre une cellule à 1, il faut passer par une autre opération matériellement différente : un effacement.
Il existe deux types de mémoire flash : NOR et NAND. Les NOR les plus simples permettent de faire des effacements sur un octet : elles sont utilisées de façon marginale pour les firmwares modifiables dans des appareils embarqués très simples (on peut y exécuter directement du code et elles ne nécessitent pas de logique particulière pour être réécrites). Les NOR modernes permettent quand à elles d'effacer les données par segments : c'est plus rapide que par octets mais cela réclame de gérer du coup des buffers de la taille des segments.

Les NAND sont les mémoires Flash utilisées par les SSD. Contrairement aux NOR elles ne sont pas adressables directement mais via un protocole série. Les opérations d'effacement ne peuvent s'effectuer que sur des blocs complets (de plusieurs dizaines de milliers de cellules). Du coup toute opération d'écriture nécessite bien d'effacer les données (bits mis à 1) d'un bloc au préalable.

Et pour ce qui concerne le fonctionnement réel du TRIM, il n'y a aucune raison pour qu'un SSD n'effectue pas ses effacements de cellules consécutifs à la commande TRIM pendant les moments où il n'est pas sollicité. Dès lors le TRIM tel que le décrit Lionel est nécessairement un facteur d'amélioration des performances.

[Darsh]

Question bête...

La fonction "Effacer l'espace libre..." de l'utilitaire de disque fonctionne avec les SSD ?
Si oui, est-ce que ça permet de préparer les cellules déjà utilisées pour une nouvelle écriture comme le fait le TRIM ?

[DefKing]

"Pour des raisons de compatibilité les SSD ont adopté le même fonctionnement que les disques durs. "

On connaît bien le système des disques mécaniques. Alors, quel pourrait être le fonctionnement d'un SSD s'il n'y avait pas ces raisons de comptabilité ?

[SartMatt]

La fonction "Effacer l'espace libre..." de l'utilitaire de disque fonctionne avec les SSD ?

Oui, elle fonctionne.
Mais pas forcément comme il faudrait : sur un SSD deux écritures successives d'un même secteur ont de bonnes chances de ne pas se faire physiquement sur la même page.
Donc quand l'effacement sécurisé écrase les données, en réalité elles ne sont pas forcément écrasées au niveau physique, donc pourraient éventuellement rester accessibles, au moins en partie. Mais là on entre dans des considérations qui dépassent largement le cadre d'un usage grand public.

Si oui, est-ce que ça permet de préparer les cellules déjà utilisées pour une nouvelle écriture comme le fait le TRIM ?

Non, cf 4ème point sur mon post un peu plus haut : http://forum.macbidouille.com/index.php?sh...p;#entry3912816

[Kierkegaard]

Question bête...

La fonction "Effacer l'espace libre..." de l'utilitaire de disque fonctionne avec les SSD ?
Si oui, est-ce que ça permet de préparer les cellules déjà utilisées pour une nouvelle écriture comme le fait le TRIM ?

Question bête à mon tour: Pourquoi n'utilises-tu pas l'utilitaire TRIM Enabler pour la Gestion de la commande TRIM sous OS X?

[Licorne31]

Question bête...

La fonction "Effacer l'espace libre..." de l'utilitaire de disque fonctionne avec les SSD ?
Si oui, est-ce que ça permet de préparer les cellules déjà utilisées pour une nouvelle écriture comme le fait le TRIM ?

Question bête à mon tour: Pourquoi n'utilises-tu pas l'utilitaire TRIM Enabler pour la Gestion de la commande TRIM sous OS X?

Dans son cas, je ne sais pas (peut-être est-il sous Yosemite, et qu'il a peur du reset NVRAM?).
Dans le mien, je suis toujours sous Tiger, avec des PPC, donc si tu connais une version de TrimEnabler (ou équivalent) qui marche dans cette configuration, je suis preneur!

[ekami]

Apple devrait simplement fournir une petite application (ou une case à cocher dans la préférence système Sécurité) permettant d'installer une version signée de l'extension intégrant la modif réalisée par Trim Enabler (tout en permettant de revenir à la version classique de l'extension).
Apple le fait bien pour les applications, pourquoi pas pour une de ses extensions ?
Il suffirait de bien préciser que l'usage de cette extension se fait "aux risques et périls" de l'utilisateur, Apple ne garantissant pas le fonctionnement du TRIM sur tous les modèles de SSD existants.
Chacun pourrait ainsi choisir en connaissance de cause l'utilisation de cette extension, (càd sans garantie de résultat), mais au moins, la sécurité de Yosemite ne serait pas compromise.

[Diogénês]

Question bête...

La fonction "Effacer l'espace libre..." de l'utilitaire de disque fonctionne avec les SSD ?
Si oui, est-ce que ça permet de préparer les cellules déjà utilisées pour une nouvelle écriture comme le fait le TRIM ?

Bonjour à tous,

2ème question bête, j'ai pris l'habitude de faire une "clean install" lors de chaque revision (majeur ) de l'OS, et donc d'intégralement formater mon SSD..
Est-ce que cela remet les "choses" à plat ou la perte est bel et bien définitive ?

Merci !

[jld73]

J'ai eu des soucis avec un Crucial M500 de 480 Go avec des kernel panic à répétition
Le SAV de Crucial m'a fait supprimer la gestion TRIM qui pouvait être incompatible avec Active Garbage Collector_j'étais sous Mavericks_ et çà n'a rien changé.
Au total c'étaient mes 16Go de RAM et le swap mémoire qui provoquaient les KP.
Entretemps je suis passé au M550 de 512 Go et à Yosemite avec les soucis que l'on sait d'utiliser le TRIM.
SAV Crucial a continué à m'affirmer que AGC remplaçait "avantageusement" le TRIM.
Si j'ai bien lu le post, vous n'êtes pas d'accord avec çà _qui pourtant m'arrangeait bien_
Où est la vérité ??

[marc_os]

J'ai eu des soucis avec un Crucial M500 de 480 Go avec des kernel panic à répétition
Le SAV de Crucial m'a fait supprimer la gestion TRIM qui pouvait être incompatible avec Active Garbage Collector_j'étais sous Mavericks_ et çà n'a rien changé.
Au total c'étaient mes 16Go de RAM et le swap mémoire qui provoquaient les KP.
Entretemps je suis passé au M550 de 512 Go et à Yosemite avec les soucis que l'on sait d'utiliser le TRIM.
SAV Crucial a continué à m'affirmer que AGC remplaçait "avantageusement" le TRIM.
Si j'ai bien lu le post, vous n'êtes pas d'accord avec çà _qui pourtant m'arrangeait bien_
Où est la vérité ??

iAPX dit que son Crucial C300 est resté réactif même après plusieurs années sans TRIM...

[benjinthesky]

Bonjour, je viens d'installer un SSD 240go OWC Mercury dans mon imac 27 de 2009 (montage DD et SSD avec Fusion drive), sur le site OWC ils indiquent qu'il n'y a pas besoin de trim, et explique leurs technologie:

http://blog.macsales.com/21641-with-an-owc...o-need-for-trim

With An OWC SSD, There’s No Need For TRIM

Ont ils raison d'indiquer cela?

Ben fait des benchs quand ton disque est vide et fais le quand ton disque a été écrit complètement au moins une fois.... je pense que tu auras des surprises.
Je pense que l'ion peut effectivement se passer de la fonction TRIM si on peut se contenter de performances degradées.

Je rajouterai que bcp de monde dont moi le 1er achetent des SSD pour leur machines mais a cause de la garantie ou pour éviter de demonter la bête se contente de les brancher en USB3 ou Firewire 800. Or la fonction TRIM est une fonctionnalité inhérente à l'interface ATA, donc tous les disques branchés via des boitiers externes fonctionnent de façon dégradés... j'ignore le cas du thunderbolt.. il s'agit de lien PCI Express il me semble.. donc pas d'espoir... seul a priori le e-sata trouverait grace.
Sans parler du fait qu'Apple bloque souvent la possibilité de mettre un disque non Apple. J'ai cru lire qu'un fabricant avait carrément proposer des disques dont l'ID vendor était Apple pour assurer une compatibilité pleine...

Merci c'est quoi "bench"?, j'ai monté mon ssd à la place du lecteur de disque donc en ATA.

[scoch]

J'ai eu des soucis avec un Crucial M500 de 480 Go avec des kernel panic à répétition
Le SAV de Crucial m'a fait supprimer la gestion TRIM qui pouvait être incompatible avec Active Garbage Collector_j'étais sous Mavericks_ et çà n'a rien changé.
Au total c'étaient mes 16Go de RAM et le swap mémoire qui provoquaient les KP.
Entretemps je suis passé au M550 de 512 Go et à Yosemite avec les soucis que l'on sait d'utiliser le TRIM.
SAV Crucial a continué à m'affirmer que AGC remplaçait "avantageusement" le TRIM.
Si j'ai bien lu le post, vous n'êtes pas d'accord avec çà _qui pourtant m'arrangeait bien_
Où est la vérité ??

iAPX dit que son Crucial C300 est resté réactif même après plusieurs années sans TRIM...

Il a aussi précisé que la baisse des performances n'était pas limitante dans SON utilisation (et celle de son ami qui avait jusque là un HDD).

Ce message a été modifié par scoch - 31 Oct 2014, 19:25.

[powerjaja]

Merci pour cette (ré)explication on ne peut plus claire et vulgarisante pour nous les p'tits lecteurs ! J'ai enfin bien compris !

Tiens ça me fait penser à une chose que je n'ai pas encore compris en revanche : comment se fait-il qu'à l'usage (en ressenti utilisateur) il y ait une si grande différence entre un disque dur ultra rapide et un SSD tout pourri ? Ou bien si peu de différence entre un SSD tout pourri et un SSD ultra haut de gamme ?