Ubuntu prend-il en charge la commande TRIM pour une utilisation avec SSD?

34

Les disques SSD doivent être "effacés / réinitialisés" une fois le disque plein pour maintenir les performances. Cela se fait via la commande TRIM pour les nouveaux lecteurs SSD. Ubuntu prend-il en charge la commande TRIM (via hdparm, etc.) pour effacer / réinitialiser ces lecteurs?

kernel ssd trim ssanj
la source
Bonne question, mais notez que le degré d'amélioration de la performance de TRIM varie selon les disques SSD. Pour certains, cela ne fait pas toute la différence qu'on pourrait le penser (même s'ils semblent surtout être les plus lents).
Nicholas Knight
1
Je pense que la performance serait restaurée de la même manière (si ce n’est pas proche) des valeurs par défaut d’usine Regardez ici pour une explication -> anandtech.com/show/2738/10
ssanj

Réponses:

24

On dirait que la fonctionnalité TRIM est prise en charge dans les versions 10.10 et suivantes:

En outre, les opérations TRIM se déroulent automatiquement: des blocs vides sont automatiquement libérés lorsqu'ils ne sont plus nécessaires (par exemple, vous supprimez un fichier), si le disque indique qu'il prend en charge TRIM. Vous n'avez pas besoin d'émettre manuellement une commande hdparm pour que cela fonctionne.

Jeremy Kerr
la source
Je pensais que vous deviez encore utiliser des outils qui "envoyaient" la commande TRIM au SDD. C'est bien si cela fonctionne comme vous le spécifiez. :) Cet article Anandtech -> ( anandtech.com/show/2738/10 ) indique que, pour que TRIM fonctionne, le système d’exploitation et le disque SSD ont tous deux besoin de la prise en charge de TRIM. Je suppose que ma question concerne le support OS / Linux pour TRIM lorsqu'il est utilisé avec des lecteurs SSD compatibles TRIM.
mardi
3
La commande TRIM doit savoir quel (s) bloc (s) à libérer, il serait donc dangereux de le faire sans savoir exactement quels blocs du disque ne sont pas utilisés. Oui, le système d’exploitation et le disque doivent avoir un support trim. Sous Linux, ceci a été ajouté à la version 2.6.33 du noyau et sera donc inclus dans Maverick. Le pilote de disque du système de fichiers que vous utilisez doit prendre en charge trim pour que cela fonctionne correctement. Si vous utilisez ext4 comme système de fichiers sur Maverick, ça devrait aller.
Jeremy Kerr
Je me demande alors s'il sera possible pour les disques SSD existants de se soumettre à une "TRIM mise à niveau" afin de nettoyer les ressources existantes accumulées avant que l'OS ne prenne en charge la TRIM. Ou une réinstallation serait-elle nécessaire?
Kent Boogaart le
20

La réponse de Jeremy n'est pas tout à fait juste, 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 sais:

  • Le noyau prend en charge TRIM à partir de la version 2.6.33 (Maverick est 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'aimerais avoir la source, car cela pourrait ne pas être vrai ou ne plus être valable.

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 à la v9.27) sont livrées avec un script appelé wiper.shqui effectue une analyse rapide du lecteur, puis coupe tout l’espace vide. Plutôt que de perdre des fonctionnalités, je trouve qu'il est beaucoup plus facile de wiper.shse lancer 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 pourraient trouver cela plus facile à utiliser que la configuration de tâches cron.

Il y a 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 supérieurs.

Oli
la source
Pouvez-vous créer un lien vers ces APP s'il vous plaît?
Jorge Castro
Donc, l'activation de l' discardoption de montage pour ext4 désactive la journalisation? Je viens de chercher des références, mais je ne peux pas en trouver une en dehors de cette réponse - pouvez-vous fournir une source?
Hamish Downer
2
dans Ubuntu 12.04 le wiper.sh a été remplacé par fstrim
tomodachi
1
@ Oli: J'ai lu un peu plus et je suis maintenant à peu près sûr que l'option de suppression ne désactive pas le journal. Afaict à l’origine, l’option de suppression fonctionnait uniquement avec le journal (j’ai trouvé ce correctif qui permet de supprimer sans le journal). La page ext4 du noyau documente l'option de suppression, mais ne mentionne pas que le journal est incompatible.
Hamish Downer
8

Linux prend en charge le système de fichiers TRIM automatique avec le système de fichiers ETX4 depuis le noyau 2.6.33.

La première version Ubuntu avec prise en charge automatique de TRIM est la version 10.10 (Maveric), mais elle doit être activée dans fstab (comme décrit ici ).

Uli
la source
4

En général, oui, car il existe une foule de moyens pour obtenir de nouveaux noyaux. Si nous clarifions votre question, veuillez lire "10.04 LTS a-t-il un support immédiat pour la commande?" alors la réponse est non. Cependant, à la fois de Maverick et les noyaux de Natty (-Générique, -Générique-pae, -server et saveurs -virtual) ont été rétroportés à 10.04 LTS et sont disponibles à partir de $ release-mises à jour dans les dépôts Ubuntu, par exemple, linux-image-generic-lts-backport-maverickest le backport de Maverick Lucid .

Daniel T Chen
la source
2

Je suis sous la version 11.04 et il ne semble pas que TRIM fonctionne correctement.

J'ai testé en utilisant les instructions ici pour créer un fichier, le supprimer et voir si les secteurs sont mis à zéro / supprimés .

J'ai essayé d'activer TRIM en utilisant les instructions ici, mais pas de dés

Je lance wiper.sh, je reçois

/sbin/wiper.sh --verbose --commit / dev / sda1
wiper.sh: Utilitaire Linux SATA SSD TRIM, version 3.3, de Mark Lord.
rootdev = / dev / sda1
fsmode2: fsmode = lecture-écriture
/: fstype = ext4
freesize = 13785252 KB, réservé = 137852 KB
Préparation pour TRIM en ligne de l’espace libre sur / dev / sda1 (ext4 monté en lecture-écriture sur /).

Cette opération pourrait détruire vos données en silence. Êtes-vous sûr (o / n)? y
Création d'un fichier temporaire (13647400 KB) ..
Synchroniser des disques ..
Début des opérations TRIM ..
get_trimlist = / sbin / hdparm --fibmap WIPER_TMPFILE.9689

/ dev / sda:
rognage de 27294800 secteurs de 462 gammes
réussi
Supprimer le fichier temporaire ..
Synchroniser des disques ..
Terminé.

Cependant, si je l'exécute à nouveau, il indique que le même nombre de secteurs / plages doit être ajusté et signale à nouveau le succès. Je reçois exactement la même chose à chaque fois. Il ne semble pas que les secteurs soient supprimés / libérés. Leur lecture montre toujours les mêmes données.

Curieux si quelqu'un d'autre le fait fonctionner.


la source
Si vous avez ajouté l'option de suppression à fstab et qu'il ne fonctionne toujours pas, il s'agit probablement d'un bogue dans l'alpha. Vous devriez déposer un rapport de bogue.
Uli
Je viens de tester cela dans natty (en suivant ces instructions: askubuntu.com/questions/18903/how-to-enable-trim ) et son fonctionnement est encore meilleur dans natty, TRIM est presque instantané.
Uli
Il est possible que vous ayez un disque SSD qui ne prend pas en charge TRIM - bon nombre des disques SSD antérieurs ne prenaient pas en charge TRIM.
Hamish Downer