TRIM
Artikel wird überarbeitet
Dieser Artikel wird momentan überarbeitet.
Geplante Fertigstellung: 31.10.2019
Derzeitig gültiger Artikel: SSD/TRIM
Bearbeiter: unbekannt1984
Solltest du dir nicht sicher sein, ob an dieser Anleitung noch gearbeitet wird, kontrolliere das Datum der letzten Änderung und entscheide, wie du weiter vorgehst.
Achtung: Insbesondere heißt das, dass dieser Artikel noch nicht fertig ist und dass wichtige Teile fehlen oder sogar falsch sein können. Bitte diesen Artikel nicht als Anleitung für Problemlösungen benutzen!
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Du möchtest den Artikel für eine weitere Ubuntu-Version testen? Mitarbeit im Wiki ist immer willkommen! Dazu sind die Hinweise zum Testen von Artikeln zu beachten.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Hinweis:
Dieser Artikel ist Teil der Artikelserie SSD, welche das Thema Solid State Drives behandelt. Dieser Artikel geht in allen Beschreibungen davon aus, dass die SSD als /dev/sda im System eingebunden ist. Die Befehle müssen bei davon abweichenden Systemen daher gegebenenfalls angepasst werden.
TRIM ist ein sehr wichtiger Befehl zur Markierung ungenutzter oder ungültiger Datenblöcke auf Speichermedien zum Zweck der späteren Wiederbeschreibung. Ausführliche Informationen zur Arbeitsweise von TRIM stehen im Artikel SSD/Begriffsdefinitionen (Abschnitt „TRIM“).
Über die Ende 2008 mit dem Kernel 2.6.28 eingeführte Discard-Funktion (englisch: discard – (etwas) verwerfen) können Dateisysteme den Kernel anweisen, dem Datenträger leere Bereiche zu melden. Seit Kernel 2.6.33 kann Linux direkt über ein ATA-Kommando diese Information (via SATA) weitergeben – nahezu alle aktuellen SSD verstehen diesen TRIM-Befehl.
Um nun die TRIM-Funktion nutzen zu können, müssen einige Voraussetzungen erfüllt sein: So müssen sowohl die SSD als auch der Kernel TRIM unterstützen. Der Artikel SSD/TRIM/Testen erklärt, wie man TRIM der SSD und des Kernels auf Funktion überprüfen kann.
Online, Batched oder lieber gar nicht?¶
Es gibt verschiedene Meinungen zur Nutzung von TRIM (siehe Abschnitt Links): Manche sprechen sich dafür aus, den TRIM-Befehl über die Mountoptionen in /etc/fstab (genannt „Online Discard“) zu setzen, andere führen TRIM manuell aus (genannt „Batched Discard“), andere wiederum sind der Meinung, dass all dies, wenn der Kernel und die SSD „trimmen“ können, kontraproduktiv sei.
Um für sich selbst und die eingesetzte Hardware die optimalen Einstellungen zu finden, sollte man mit den einzelnen Einstellungen die Performancetests durchführen und sich dann für die jeweilige beste/schnellste Lösung entscheiden. Weiterhin sollte man ggf. eine Messung der Dauer eines Batched-Discards durchführen, falls man besorgt ist, das System könnte stundenlang blockiert werden.
Seit Ubuntu 18.04 wird zumeist ein Systemd Timer für einen wöchentlichen Batched Discard erzeugt und aktiviert. Dies kann man durch Ausgabe der Liste der Timer verifizieren:
systemctl list-timers --all
NEXT LEFT LAST PASSED UNIT ACTIVATES Sun 2019-10-13 19:30:44 CEST 14min left Sun 2019-10-13 18:32:01 CEST 44min ago anacron.timer anacron.service Sun 2019-10-13 20:58:14 CEST 1h 41min left Sat 2019-10-12 20:58:14 CEST 22h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2019-10-13 23:54:32 CEST 4h 37min left Sun 2019-10-13 11:39:01 CEST 7h ago apt-daily.timer apt-daily.service Mon 2019-10-14 00:00:00 CEST 4h 43min left Sun 2019-10-13 00:00:04 CEST 19h ago exim4-base.timer exim4-base.service Mon 2019-10-14 00:00:00 CEST 4h 43min left n/a n/a fstrim.timer fstrim.service Mon 2019-10-14 00:00:00 CEST 4h 43min left Sun 2019-10-13 00:00:04 CEST 19h ago logrotate.timer logrotate.service Mon 2019-10-14 00:00:00 CEST 4h 43min left Sun 2019-10-13 00:00:04 CEST 19h ago man-db.timer man-db.service Mon 2019-10-14 06:19:31 CEST 11h left Sun 2019-10-13 06:02:01 CEST 13h ago apt-daily-upgrade.timer apt-daily-upgrade.service Sun 2019-10-20 03:10:37 CEST 6 days left Sun 2019-10-13 03:11:01 CEST 16h ago e2scrub_all.timer e2scrub_all.service 9 timers listed.
Hier wurde der Timer fstrim.timer aktiviert aber noch nie ausgeführt (Spalten LAST und PAST lauten "n/a").
Sofern man den Batched Discard bevorzugt und der entsprechende Timer aktiv ist, braucht man sich um nichts weiter zu kümmern. Andernfalls muss man den Timer deaktivieren (sofern man den Discard gar nicht oder manuell ausführen möchte) und ggf. den Online Discard in der /etc/fstab aktivieren - sofern ein Online Discard gewünscht ist.
Messung der Dauer bei manuellem Discard¶
time sudo fstrim -Av
führt (nach entsprechender Bearbeitungszeit) zu einer ähnlichen Ausgabe wie folgt:
/: 4,6 GiB (4934770688 bytes) trimmed real 0m8,644s user 0m0,015s sys 0m0,777s
In diesem Fall handelte es sich um eine einfache SanDisk SSD-Plus mit 240GB, entsprechend greifen die Beschränkungen des SATA-Busses (ca. 550 MB/s max Datentransfer). Einen kurzen "Hänger" von ca. 10 Sekunden kann man in den meisten Fällen verkraften, sollte jedoch die Datenmenge (und entsprechend die Bearbeitungszeit) wesentlich höher ausfallen, so sollte man ggf. die Häufigkeit der Bereinigung erhöhen oder auch die Bereinigung verlangsamen, um an dem entsprechendem Rechner noch arbeiten zu können.
Welches Dateisystem (Journaling)¶
Laut Computermagazin c't kompakt 01/2012 Linux ist die Wahl des besten Dateisystems zurzeit ext4, da dessen Arbeitsweise der SSD entgegenkommt. In Zukunft kann das sich noch in der Entwicklung befindliche Dateisystem Btrfs das Rennen um das beste Dateisystem für SSD machen, bietet es doch speziell auf die Betriebsart von SSD zugeschnittene Arbeitsweisen und die Vermeidung von Overhead.
Die vermeintlichen Tipps, ein Abschalten des Journalings steigere die Performance der SSD und verringere die Schreibzugriffe auf selbige, halten sich hartnäckig im Netz. Die nötigen Schreibvorgänge verringern sich durch das Abschalten tatsächlich, allerdings nimmt man ein weitaus höheres Risiko eines Datenverlustes in Kauf, so dass dieses Risiko den Performance-Vorteil nicht wert ist. Der sogenannte Overhead, der durch das Journaling entsteht, liegt nur zwischen vier und zwölf Prozent.
Exkurs - Journaling auf SSD¶
Wie Theodore 'Ted' Ts'o, Hauptentwickler des Dateisystems ext, beschreibt 🇬🇧 , kann man bei modernen SSD das sogenannte Journal ebenfalls auf die SSD schreiben, ohne dass diese dadurch Schaden nehmen. Es gehe dabei eher um ältere Modelle der SSD, welche noch nicht vom Wear Levelling geschützt waren. Ts'o schreibt, dass Intel für seine SSD angibt, dass diese mindestens fünf Jahre laufen. Intel legte dazu den Parameter bei 10 Gigabyte an zu schreibenden Daten pro Tag fest (siehe auch Haltbarkeit der SSD).
Abschalten des Journalings¶
Achtung!
Das Abschalten des Journalings birgt einige schwerwiegende Risiken und sollte wirklich nur von Anwendern vollzogen werden, die wissen was sie tun!
Möchte man wirklich das Journaling abschalten, so kann man eine ext4-Partition wie folgt im Terminal [3] partitionieren:
mke2fs -t ext4 -O ^has_journal /dev/sda
Des Weiteren sollte man, falls man das Journaling aktiviert lässt, zumindest die Mountoption data=writeback in die Datei /etc/fstab eintragen. Im Abschnitt Links gibt es eine ausführlichere Beschreibung der Option data=writeback, die Manpage von tune2fs ist noch ergiebiger.
TRIM (ext4)¶
Eine SSD lässt sich ausgezeichnet unter dem aktuellen Ubuntu-Dateisystem namens ext4 betreiben.
Hinweis:
ext4 ist seit Ubuntu 9.10 Karmic Koala das Standard-Dateisystem Ubuntus. Demnach geht dieser Artikel auch nur auf ext4 als Dateisystem ein. Bei Fragen zu Unterschieden zwischen ext2, ext3 und ext4 sei auf das ext-Wiki 🇬🇧 verwiesen (siehe Links).
Linux unterstützt zwei Arten des Discard (nähere Details in der nachfolgenden Tabelle):
„Batched Discard“ – Der Befehl
fstrim /mnt/point/weist das Dateisystem an, ungenutzte Bereiche zu suchen und diese dem Controller der SSD zu melden. Dieser Befehl muss sporadisch und manuell vom Anwender ausgeführt werden.„Online Discard“ – Der Kernel informiert das Laufwerk sofort, wenn Speicherbereiche durch Löschen von Dateien frei werden. Diese Funktion ist von Haus aus deaktiviert und muss vom Anwender in /etc/fstab mit der Option
discardeingeschaltet werden.
| Fähigkeit des Dateisystems, einen „Batched Discard“ oder „Online Discard“ durchzuführen | |||
| Batched Discard | Online Discard | ||
| Dateisystem ext4 | ab Kernel 2.6.37 | Dateisystem ext4 | ab Kernel 2.6.33 |
| Dateisysteme ext2, ext3, XFS | ab Kernel 2.6.38 | Dateisystem XFS | ab Kernel 3.0 |
| Dateisystem Btrfs | ab Kernel 2.6.39 | Dateisystem Btrfs | ab Kernel 2.6.32 |
| Dateisysteme NTFS-3G, FAT | – | Dateisysteme NTFS-3G, FAT | – |
Automatisches TRIM ab Ubuntu 14.10¶
Mit Ubuntu 14.10 wird ein wöchentliches, automatisches TRIM ausgeführt. Dazu gibt es das Skript fstrim im Verzeichnis /etc/cron.weekly, das wiederum /sbin/fstrim startet. Man kann dieses Skript, wie unter TRIM per Batched Discard beschrieben, ändern, so dass man die dort beschriebene Log-Datei erhält:
1 2 3 4 5 6 7 | #!/bin/sh # trim all mounted file systems which support it # /sbin/fstrim --all || true LOG=/var/log/batched_discard.log echo "*** $(date -R) ***" >> $LOG /sbin/fstrim -v / >> $LOG /sbin/fstrim -v /home >> $LOG |
Eine Ausgabe sieht dann z.B. so aus:
*** Sun, 12 Oct 2014 12:51:07 +0200 *** /: 290,9 MiB (305029120 bytes) trimmed /home: 116,4 MiB (122036224 bytes) trimmed
Möchte man eine vorhandene SSD von einem Hersteller auto-trimmen, der nicht auf der Whitelist steht (weil man sich sicher ist, dass die eigene SSD nicht von diesen Problemen betroffen ist), kann man in der Datei /etc/cron.weekly/fstrim die Option --no-model-check an den fstrim-Befehl hängen, so dass das Skript dann wie folgt aussieht:
1 2 3 4 5 6 7 8 9 10 | #!/bin/sh # call fstrim-all to trim all mounted file systems which support it set -e # This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty # firmware may encounter data loss problems when running fstrim under high I/O # load (e. g. https://launchpad.net/bugs/1259829). You can append the # --no-model-check option here to disable the vendor check and run fstrim on # all SSD drives. exec fstrim-all --no-model-check |
TRIM per Batched Discard¶
Trimmen per „Batched Discard“ ist sehr einfach. Dies kann man manuell mit folgendem Befehl in einem Terminal [1] mit Root-Rechten [2] oder aber regelmäßig zum Beispiel per Cronjob durchführen.
sudo fstrim -v / ## oder sudo fstrim -v /home
Als Ausgabe erhält man mit der Option -v eine Ausgabe, wie viele Bytes getrimmt wurden:
/home: 1825476608 bytes were trimmed
In diesem Beispiel wurden ungefähr 1,825 GB getrimmt. Wie oft man dieses Verfahren anwenden muss und wie lange es dann jeweils dauert, hängt sehr stark vom eigenen Gebrauch der SSD bzw. deren Benutzung ab, so dass man dafür keinerlei Empfehlung abgeben kann.
Will man ein Batched Discard regelmäßig automatisch ausführen lassen, so erzeugt man mit einem Editor mit Root-Rechten die Datei /etc/cron.weekly/batched_discard (wöchentlich) bzw. /etc/cron.daily/batched_discard (täglich) mit folgendem Inhalt:
1 2 3 4 5 | #!/bin/sh LOG=/var/log/batched_discard.log echo "*** $(date -R) ***" >> $LOG fstrim -v / >> $LOG fstrim -v /home >> $LOG |
Da der Cronjob mit Root-Rechten ausgeführt wird, ist hier kein sudo erforderlich.
Danach muss die Datei noch ausführbar gemacht werden, z.B. mit
sudo chmod 755 /etc/cron.weekly/batched_discard
Dieses Beispiel setzt voraus, dass sich auf der SSD eine Root- und eine Home-Partition befinden - ist dies nicht der Fall, muss der Code entsprechend angepasst werden.
Die Ergebnisse des Cronjobs werden mit Zeitstempel versehen in die Logdatei /var/log/batched_discard.log geschrieben. Zum Ansehen verwendet man das Kommando
tail /var/log/batched_discard.log
TRIM per Online Discard¶
Hinweis:
Für SSDs der ersten Baureihen fanden sich Berichte, wodurch die per „Online Discard“ entstehenden TRIM-Befehle die Performance der SSD reduzieren oder diese unbenutzbar machen könnten. Bei aktuellen SSDs ist dieses Problem nicht bekannt.
Ab Ubuntu 14.04 sollte man bei den Marken-SSD (Intel, Samsung, OCZ, SanDisk sowie Patriot) auf diesen Eintrag in der /etc/fstab verzichten. Dann wird der TRIM-Befehl über /etc/cron.weekly/fstrim bzw. eine systemd Timer Unit aufgerufen.
Exkurs - Mountoption relatime¶
Aktuelle Ubuntuversionen binden Laufwerke von Haus aus mit der mount-Option relatime (Relative Access Time) ein, was die Arbeit der SSD deutlich erleichtert. (Das ausdrückliche Hinzufügen dieser Mountoption in der /etc/fstab ist seit Ubuntu 8.04 nicht mehr notwendig.) Der Kernel aktualisiert die letzte Zugriffszeit (Access Time) auf Dateien dann nur in bestimmten Zeitintervallen, die jedoch für nahezu alle Programme vollkommen ausreichend sind.
Des Weiteren kann man, möchte man das Journaling nicht komplett abschalten (siehe Exkurs: Journaling auf SSD), die Mountoption data=ordered in /etc/fstab eintragen, welche einen guten Kompromiss zwischen vollem Journaling und gar keinem darstellt.
Ein Vergleichstest zwischen de- und aktivierter Mountoption discard ist unter Links zu finden.
TRIM mit Festplattenverschlüsselung¶
Achtung!
Wird TRIM auf verschlüsselten Festplatten benutzt, werden dabei sehr wahrscheinlich Informationen über wenig oder unbenutzte Sektoren oder sogar Informationen über den Inhalt der Daten "geleakt". Siehe diesen englischen Artikel für Details.
Damit ein „Batched Discard“ oder „Online Discard“ auf einer mit dm_crypt (LUKS) verschlüsselten Festplatte funktioniert, muss zusätzlich zur Datei /etc/fstab auch in der Datei /etc/crypttab die discard-Option eingetragen werden [2][3]. Dazu fügt man hinter die Zeile des verschlüsselten Gerätes die Option discard ein (im Beispiel gelb markiert):
sda3_crypt UUID=e364d03f-[...]6cd7e none luks,discard
Wenn das System sogar mit Schlüsselableitung voll verschlüsselt ist, muss zusätzlich die Datei /etc/initramfs-tools/conf.d/cryptroot auf analoge Weise angepasst werden:
target=sda3_crypt,source=UUID=e364d03f-[...]6cd7e,discard,[...]
Dabei kann der Name des verschlüsselten Gerätes je nach Art der Installation vom hier gezeigten Beispiel "sda3_crypt" abweichen. Danach ist noch das initramfs mit:
sudo update-initramfs -u -k all
zu aktualisieren.
Nach dem Neustart sollte TRIM tadellos funktionieren. Mit:
sudo dmsetup table /dev/mapper/sda3_crypt
kann überprüft werden ob die discard-Option aktiv ist (sda3_crypt ist entsprechend anzupassen, falls das Gerät anders heißt):
0 975718448 crypt aes-xts-plain64 00000000 0 8:2 4096 1 allow_discards
Falls am Ende allow_discards steht, ist alles ok.
TRIM der Swap-Partition¶
Seit Version 2.6.29 kann der Kernel TRIM per Discard auf Swap-Partitionen durchführen. „Online Discards“ können auch hier zu Einbußen der Performance der SSD führen. Seit Kernel 2.6.36 ist TRIM auf Swap-Partitionen daher optional und muss vom Anwender über die Swapon-Option -d oder über /etc/fstab und der Option discard aktiviert werden.
Davon unabhängig führt Swapon beim ersten Start des Swap einen Discard aus, was für normale Desktops und Notebooks, die nur ab und zu Speicher in den Swap auslagern, vollkommen ausreichend ist. Anwender, die damit leben können, brauchen also für die Swap-Partition keine Vorkehrungen bezüglich TRIM/Discard treffen.
TRIM mit Btrfs¶
Achtung!
Benutzt man btrfs als Dateisystem, sollte das Skript wiper.sh auf keinen Fall angewendet werden (siehe Abschnitt Links – Projekt hdparm/wiper.sh)!
Setzt man btrfs als Dateisystem ein, so ist das Journaling nicht so umfangreich wie beim Dateisystem ext, da btrfs nur Metadaten speichert. Metadaten-Journaling garantiert lediglich die Konsistenz des Dateisystems, wohingegen beim Full-Journaling (ext3/ext4) auch die Konsistenz der Dateiinhalte gewährleistet wird. (siehe Journaling-Dateisystem).
Wurde bei einer Installation btrfs als Dateisystem ausgewählt, wird automatisch die Mountoption -o ssd gesetzt, sofern eine SSD als Festplatte erkannt wurde. Laut Btrfs-Wiki 🇬🇧 geschieht dies per Standard ab Kernel 2.6.31. Man kann diese Mountoption jederzeit manuell nachtragen/entfernen.
Die Mountoption ssd sorgt für Folgendes:
Platziert neue Abgrenzungen in Bereiche, die mehrheitlich nicht belegt sind ("Places new extents into areas that are mostly free")
Kombiniert neue Schreibvorgänge von vielen verschiedenen Dateien ohne eine Fragmentierung zu verhindern ("Combines new writes from many different files without trying to prevent fragmentation")
Effektiv mit high-end SSD (Effective on high end SSD)
Des Weiteren kann man auch die folgenden Btrfs-Mountoptionen setzen:
ssd_spreadPlatziert neue Abgrenzungen in Bereiche, die mehrheitlich nicht belegt sind ("Places new extents into areas that are mostly free")
Überschreibt einen kompletten gelöschten Block auf der SSD ("More likely to overwrite an entire erasure block in the SSD")
Man sollte nicht die Option
discard(ab Kernel 2.6.32) verwenden, siehe Verbotene-Mountoptionen.
Mit dem Befehl
cat /sys/block/sda/queue/rotational
im Terminal [3] kann man überprüfen, ob die eben gemachten Änderungen in /etc/fstab – nach einem Neustart des Rechners – korrekt übernommen wurden. Das Ergebnis sollte 0 sein.
Hinweis:
Ein gesondertes Setzen der Option für einen TRIM-Befehl ist ab Ubuntu 14.04 nicht mehr erforderlich. Dies wird über die Datei /etc/cron.weekly/fstrim erledigt.
Links¶
Weiterführende Informationen zu TRIM:
TRIM pro und contra:
Projekt hdparm/wiper.sh:
Informationen zu ext4:
Journaling bei ext4:
Informationen zu btrfs:
btrfs Filesystem – SSD Optimizations (PDF) 🇬🇧 Folie 16 des Oracle-Vortrages auf der LinuxCon North America 2010