La réponse de Jeremy n’est pas tout à fait exacte, autant que je sache. Cela fait quelque temps que je fais tourner les derniers noyaux stables sur Lucid et je suis très attentif au statut de TRIM, car j'ai un disque principal OCZ Agility.
Voici ce que (je pense) je sais:
-
Le noyau prend en charge TRIM à partir de la version 2.6.33 (Maverick est la version 2.6.35).
-
EXT4 prend en charge TRIM mais uniquement lorsque la journalisation est désactivée.
-
Le fonctionnement de TRIM dans le noyau est très basique et assez lent. Les disques conformes aux spécifications peuvent accepter plusieurs plages, mais le noyau ne peut actuellement en faire qu’une plage à la fois. Cela vient de quelque chose que j'ai lu il y a peut-être un mois. J'aurais aimé avoir la source, car cela pourrait ne pas être vrai ou ne plus être d'application.
La journalisation est ce qui la tue pour moi. La corruption de données est un PITA.
Cependant, les versions les plus récentes de hdparm (v9.25 - Maverick est à v9.27) sont accompagnées d’un script appelé wiper.sh
qui effectue une analyse rapide du lecteur, puis élimine tout l’espace vide. Plutôt que de perdre des fonctionnalités, je trouve qu'il est beaucoup plus facile de créer wiper.sh
une fois par semaine (ou une fois par jour / mois / peu importe). La dégradation de SSD pour un lecteur de système d'exploitation ne se produit pas aussi rapidement, à moins que vous ne démontiez constamment les choses. Vous n'avez pas besoin de TRIMming en temps réel.
Il existe également une interface graphique appelée DiskTRIM qui ne semble pas figurer dans le dépôt. Les utilisateurs moins expérimentés peuvent trouver cela plus facile à utiliser que la configuration de tâches cron.
Il existe des PPA pour hdparm et disktrim et tous peuvent être exécutés sur Lucid (et un peu plus en arrière) sans avoir besoin de noyaux 2.6.33 ou plus.