Was macht TRIM?¶

Ein Dateisystem wie z.B. ext4 oder btrfs kennt die beiden Klassen

• belegte Speicherblöcke (cluster), in denen aktuelle Dateien gespeichert sind und

• freie Speicherblöcke, die entweder noch nie benutzt wurden oder in denen Teile von gelöschten Dateien gespeichert sind. Wenn eine neue Datei gespeichert werden soll, wird der benötigte Speicherplatz diesem Pool entnommen, wobei zwischen „nie benutzt“ und „gelöscht“ nicht differenziert wird.

Eine SSD kennt dagegen

• benutzte Speicherblöcke (pages), in denen aktuelle oder gelöschte Daten gespeichert sind und

• unbenutzte Speicherblöcke, die für die Speicherung neuer oder aktualisierter Daten verwendet werden können. Das bedeutet: Die Änderung auch nur eines Bits in einer existierenden Datei belegt mindestens einen weiteren Speicherblock auf der SSD.

Der Befehl TRIM (und seine Verwandten) dient dazu, dem Gerät die Sicht des Dateisystems zu vermitteln, damit auf dem Gerät Bereiche mit gelöschten Daten wieder für neue Zwecke benutzbar werden. Zur Überführung eines benutzten Speicherblocks in den Zustand „unbenutzt“ muss dieser tatsächlich gelöscht werden, was die SSD altern lässt. → SSD/Begriffsdefinitionen (Abschnitt „TRIM“)

Zur Minimierung von Schreibzugriffen auf eine SSD und damit später notwendigen TRIM-Aktionen kann man flankierende Maßnahmen (die natürlich auch Nachteile haben) ergreifen:

• Einbinden von Dateisystemen stets mit der Option relatime (ist inzwischen Standard) oder sogar mit noatime.

• Abschalten oder Reduzierung der Journal-Einträge z.B. bei einem Dateisystem ext4.

Voraussetzungen¶

Die Nutzung von TRIM bedarf einiger Voraussetzungen:

• Das Gerät – die SSD – muss es unterstützen. Dies darf inzwischen (Stand 2024) für jede neu produzierte SSD als gegeben vorausgesetzt werden. Lediglich bei uralten Exemplaren aus den ersten Baureihen kann es noch fraglich sein. → Unterstützt mein Gerät TRIM?

• ⚓︎Der Kernel unterstützt es seit Ende 2008 ab Version 2.6.28 mit der Funktion Discard (englisch: discard – (etwas) verwerfen); diese ist für den Anwender über verschiedene Wege zugänglich:

  • Das Programm hdparm kennt Optionen --trim… für Experten.

    Achtung!

    Das Paket hdparm enthält auch das Skript wiper.sh, welches man auf keinen Fall ohne vorheriges Lesen seiner Dokumentation starten sollte! Auch nach dem Lesen der Dokumentation startet man es besser nicht, es droht Datenverlust.

  • Manche Dateisysteme, insbesondere ext2 und btrfs kennen Optionen wie z.B. discard, mit denen man beim Einbinden des Dateisystems die automatische Verwendung von TRIM konfigurieren kann.

  • Es gibt die Dienstprogramme blkdiscard und fstrim, mit derer Hilfe man mit Rootrechten^[2] für das gesamte Gerät oder selektiv für ein Dateisystem oder auch für einzelne Speicherbereiche TRIM ausführen lassen kann. In diesem Artikel wird im folgenden Text nur der Befehl fstrim aus dem Paket util-linux verwendet.

• Man muss als Anwender bereit sein, TRIM auch anzuwenden bzw. zuzulassen. Aus der Einführungsphase von SSDs gibt es noch Relikte damaliger heftiger Diskussionen mit ernsthaften Bedenken zu TRIM – die aber aus heutiger (2024) Sicht nicht mehr relevant sind.

Vorteile und Nachteile¶

TRIM ist kein Werkzeug zur Steigerung der Geschwindigkeit einer SSD, sondern dient zur Bereinigung von Speicherbereichen. Unnötig (d.h. mit veralteter Information) belegte Bereiche werden einer möglichen Wiederverwendung zugeführt. Diesem einzigen Vorteil stehen als Nachteile gegenüber:

• Bei der Durchführung einer TRIM-Aktion kommt es unvermeidlich zur Unterbrechung der Arbeitsfähigkeit des betroffenen Datenträgers. Dies kann auch, insbesondere wenn das auf / eingebundene Root-Dateisystem getrimmt wird, zum zeitweisen Einfrieren des Systems führen, dessen Dauer abhängig vom Umfang vorheriger Änderungen auf dem Datenträger unmerklich kurz, wenige Sekunden oder auch störend lang sein kann. Zur Abhilfe kann man die TRIM-Aktionen auf Zeiten schwacher Systemnutzung legen.

• Jede durchgeführte TRIM-Aktion lässt die SSD altern. Zur Abhilfe sollte man TRIM-Aktionen nicht zu häufig ausführen, regelmäßig Backups anfertigen und ein Ersatzgerät bereit halten.

• → Trim_(computing)

Für Tests der Performance, auch bei SSDs, lese den Artikel Festplatten-Geschwindigkeitstest.

TRIM Strategien¶

Linux unterstützt TRIM durch den Aufruf einer internen Funktion Discard. Dies kann praktisch auf zwei unterschiedlichen Wegen erfolgen:

• "Batched Discard", auch "periodic TRIM" – Der Befehl fstrim 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 oder als periodisch ausführbare Aktion im System definiert werden.

• "Online Discard", auch "continuous TRIM" – Der Kernel informiert das Laufwerk sofort, wenn Speicherbereiche durch Löschen von Dateien frei werden.

  • Diese Funktion ist bei ext4 von Haus aus deaktiviert und muss vom Anwender mit der Option discard eingeschaltet werden.

  • Bei Btrfs kann sie unter bestimmten Umständen automatisch aktiviert werden und sollte ggf. mit der Option nodiscard ausgeschaltet werden. → Btrfs unter Sonderfälle

fstrim¶

Das Programm fstrim für die Kommandozeile^[1] stammt aus dem Paket util-linux, welches bei jeder Installation von Ubuntu bereits mit installiert wird. Es kann mit Rootrechten^[2] mit folgender allgemeiner Syntax aufgerufen werden:

fstrim OPTIONen EINBINDEPUNKT 

Das Programm bearbeitet eingebundene Dateisysteme; diese können entweder über Optionen -a, -A, -I oder -t bzw. deren Langform identifiziert werden, oder es wird über den Parameter EINBINDEPUNKT eines explizit angegeben.

Man kann in einer anderen (hier nicht besprochen) Betriebsart auch einen über die Optionen -o, -l und -m bzw. deren Langform beschrieben Bereich auf einem Datenträger bearbeiten lassen. Diese und die vorgenannte Betriebsart kann man vermischen. Lese hierzu Details in der Manpage von fstrim.

Batched Discard¶

Trimmen per "Batched Discard" ist sehr einfach. Es läuft hinaus auf einen Aufruf des Befehls fstrim:

• manuell in einem Terminal^[1] mit RootRechten^[2]

• oder per Skript

• oder periodisch per Cronjob (nicht empfohlen)

• oder periodisch per Systemd-Unit

sudo fstrim -v /home 

/home: 1825476608 bytes were trimmed

1
2
3
4
5
6
7

# !/bin/bash
{
echo "*** $(date -R) ***"
for MP in / /home     # <-- Anpassen auf die eigenen Bedürfnisse
do   /sbin/fstrim -v "$MP" || echo Fehler beim trimmen von $MP
done
} | tee >>/var/log/batched_discard.log

*** Sun, 12 Oct 2014 12:51:07 +0200 ***
/: 290,9 MiB (305029120 bytes) trimmed
/home: 116,4 MiB (122036224 bytes) trimmed

# /etc/systemd/system/UU-fstrim.service
[Unit]
Description=Discard unused blocks on filesystems from /etc/fstab
Documentation=man:fstrim(8)
ConditionVirtualization=!container

[Service]
Type=oneshot
ExecStart=/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
PrivateDevices=no
PrivateNetwork=yes
PrivateUsers=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
SystemCallFilter=@default @file-system @basic-io @system-service

Online Discard¶

Diese Methode ist zwar einfach zu konfigurieren, aber ihre richtige Anwendung ist dennoch sehr anspruchsvoll. Man benötigt umfangreiches Fachwissen, detaillierte Kenntnisse über die Implementierung im Linux Kernel und genaue Kenntnis der technischen Spezifikationen der verbauten SSD (Hardware) sowie deren Verhalten (Fehler in der Firmware). Dieser Abschnitt richtet sich an Experten und enthält keine vollständige Übersicht und erst recht keine für Laien taugliche Anleitung.

Manche SSDs sind bekannt für ihre fehlerhafte Implementierung mancher ATA-Befehle im Kontext TRIM und deshalb im Linux Kernel (genauer in der libata) für bestimmte Betriebsweisen gesperrt. Eine fehlende Mitgliedschaft in dieser schwarzen Liste ist natürlich keine Garantie für fehlerfreie Funktion, sondern bedeutet nur fehlende Erkenntnisse über das betreffende Gerät.

Zur Nutzung von "Online Discard" muss man beim Einbinden die (bzw. abhängig von Dateisystemtyp eine verwandte) Option discard verwenden. Mit einer solchen Option fordert der Dateisystemtreiber fortlaufend TRIM von der SSD an, sobald im Dateisystem Speicherbereiche frei werden. Die Details kann man in der Dokumentation des jeweiligen Dateisystems nachlesen. Siehe auch die folgenden Abschnitte für ext4, Btrfs und Swap.

Swap¶

Auslagerungsspeicher (Swap) für die virtuelle Speicherverwaltung kann dem System per Datei oder Partition bereit gestellt werden. TRIM auf Swap-Partitionen ist optional und muss vom Anwender beim Programm Swapon mit der Option -d oder über /etc/fstab^[4] mit einer Option discard aktiviert werden.

• Eine Auslagerungsdatei ist Teil des unter / eingebundenen Root-Dateisystems und wird daher vom "Batched Discard oder "Online Discard" von / mit berücksichtigt.

• Ein Swap-Partition hat aber auch im Gebrauch keinen Einbindepunkt und wird daher standardmäßig von der Unit fstrim.service per "Batched Discard" nicht bearbeitet.

  • Man kann Swap per "Batched Discard" mit einem solchen Aufruf trimmen:

    fstrim -v -I /proc/swaps 

  • Es ist optional möglich, "Online Discard" zu verwenden; hierzu muss man in der Datei fstab^[4] eine Option discard nach Tabelle 4 angeben.

Ob ein Trimmen der Swap-Bereiche überhaupt sinnvoll ist, hängt von der konkreten Hardware der SSD ab. Die Manpage von swapon führt dazu aus:

This (discard or trim) may improve performance on some Solid State Devices, but often it does not.

Ext4¶

Bei einem Dateisystem ext4 kann man "Online Discard" über 2 unterschiedliche Methoden aktivieren:

1. Man gibt die Option discard beim Einbinden der Quelle an, z.B. in der Datei fstab:
   

   /dev/sda99   /   ext4   errors=remount-ro,noatime,discard   0 1 

   Die Option noatime ist hier nicht erforderlich für discard, minimiert aber generell Schreibvorgänge und damit die Erfordernis für TRIM. In der Praxis sollte man statt einem unzuverlässigen temporären Bezeichner wie sda99 besser einen permanenten wie z.B. eine UUID verwenden.

2. Man konfiguriert die Option discard als Standardoption im Superblock des Dateisystems auf der Quelle:

   sudo tune2fs -o discard /dev/sda99 

Beachte: Sollte ich Online Discard verwenden?

Btrfs¶

Das Dateisystem Btrfs benutzt im Gegensatz zu ext4 Copy-On-Write und verschärft damit die TRIM-Problematik, denn das unterlagerte Gerät kann nun nicht mehr erkennen, dass von Anwenderseite ein Überschreiben vorhandener Daten beabsichtigt ist und dies ggf. durch selbst ausgelöste TRIM-Aktionen nachvollziehen. (Der Umstand, dass die SSD ein beabsichtigtes Überschreiben erkennen könnte, bedeutet aber nicht, dass jede SSD das auch macht und schon gar nicht, dass sie selbst TRIM auslösen würde!)

Die beim Dateisystemtyp btrfs für TRIM relevanten Optionen listet folgende Tabelle 5. Details zu den Optionen lese im Artikel „Mountoptionen BTRFS“.

Dank mit der Version des Kernels wechselnder Vorgaben und Automatiken ist die Situation unübersichtlich. Es ist schwer herauszufinden, welche Optionen im eigenen System konkret gelten und diese müssen auch nicht für die konkret verbaute SSD optimal sein.

Man sollte daher bei Btrfs grundsätzlich immer die relevanten Optionen selbst explizit vorgeben. Ein vernünftiger Ausgangspunkt für individuelle Optimierungen ist eine solche Zeile für die Quelle in fstab:

/dev/sda99   /   btrfs   noatime,ssd,nodiscard   0 1 

In der Praxis sollte man statt einem unzuverlässigen temporären Bezeichner wie sda99 besser einen permanenten wie z.B. eine UUID verwenden.

Verschlüsselung¶

Damit ein „Batched Discard“ oder „Online Discard“ auf einer mit dm_crypt (LUKS) verschlüsselten SSD funktioniert, muss man den Device Mapper anweisen, empfangene TRIM-Anforderungen an die Hardware weiterzugeben. Die Umsetzung dieser Anforderung unterscheidet sich etwas, je nachdem ob es sich bei dem betroffenen Dateisystem

• um das Root-Dateisystem,

• oder ein Dateisystem für Anwenderdaten auf einer internen SSD,

• oder um eine externe SSD handelt.

target=SDA99,source=/dev/sda99,discard,[...]

sudo update-initramfs -u -k all 

sudo dmsetup table /dev/mapper/SDA99 

0 975718448 crypt aes-xts-plain64 00000000 0 8:99 4096 1 allow_discards

Ist TRIM erforderlich?¶

Antwort: Nein und ja.

• Nein: Im produktiv laufenden System ist TRIM nicht erforderlich, aber sinnvoll. Wenn man es abschaltet, werden sich auf der SSD Leichenteile von gelöschten oder geänderten Dateien ansammeln und den freien Speicherplatz reduzieren. Solange es auf der SSD noch hinreichend viele unbenutzte Speicherblöcke gibt, wird man davon gar nichts bemerken und auch die Schreibgeschwindigkeit wird nicht beeinträchtigt. Man hat sogar den Vorteil, dass man kein Einfrieren des Systems während der Ausführung von TRIM ertragen muss.

• Ja: Irgendwann wird man in einem System mit deaktiviertem TRIM den Zustand erreichen, dass die unbenutzen Speicherbereiche auf der SSD knapp werden. Dann erst wird sich die Schreibgeschwindigkeit verringern und schließlich wird es unmöglich, neue Dateien zu speichern, obwohl aus Sicht des Dateisystems genügend Speicherplatz frei ist. Jetzt spätestens muss man das System aus dem produktiven Betrieb nehmen, ein Wartungssystem booten und die aufgesparten TRIM nachholen – das kann fallweise durchaus eine sinnvolle Strategie sein.

Wenn man im laufenden System auf TRIM verzichtet, sollte man den möglichen Speicherplatz auf der SSD nicht vollständig ausnutzen, sondern bewusst ca. 10% frei lassen. Dies kann man auf mehreren Wegen erreichen:

• Man vergrößert die "spare area", einen Speicherbereich, der im normalen Betrieb nicht sichtbar ist und exklusiv der Firmware der SSD zu Verfügung steht. Dies ist nur bei manchen SSDs möglich.

• Man partitioniert den Datenträger und lässt dabei einen Bereich einfach frei.

• Man partitioniert den Datenträger und legt dabei eine Partition an, die man nicht formatiert. Man kann optional zur Dokumentation der Partition ein Label wie z.B. "Overprovision: DO NOT USE THIS!" geben.

Overprovision kann helfen, den produktiven Betrieb aufrecht zu erhalten, aber nicht endlos. Irgendwann benötigt man den Wartungslauf.

⚓︎

Unterstützt mein Gerät TRIM?¶

Die definitive Antwort findet man in den technischen Spezifikationen zur betreffenden Hardware.

Oft reicht aber auch eine Abfrage aus dem laufenden System mit lsblk:

lsblk -dD -le7 -o+MODEL,REV 

Beispielausgabe:

NAME
    DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO MODEL                          REV
sda        0        4K       0B         0 HGST HTS725032A7E635 OPAL GHB6B8Y0
sdb        0      512B       2G         0 TS512GMTS430S             2202U17A
sdc        0      512B       0B         0 Samsung SSD 850 EVO 250GB EMT02B6Q

Relevant sind die Zahlen für DISC-MAX, welche die maximale Größe eines mit TRIM zu verwerfenden Bereiches angeben. Im Beispiel bedeuten bei sda und sdc die Maximalgrößen 0, dass TRIM nicht unterstützt wird. Das mag im Falle der Samsung 850 EVO überraschen, denn diese Hardware unterstützt lt. Spezifikation des Herstellers ausdrücklich TRIM, allerdings ist – was in der Ausgabe nicht erkennbar ist – die SSD in ein Gehäuse mit USB/SATA-Wandler eingebaut, der offenbar TRIM-Befehle blockiert, und das ist leider bei diesen Gehäusen oft so.

Wenn wie im Beispiel bei sdb unter DISC-MAX keine 0 steht, dann ist noch die Angabe für DISC-GRAN auch im Kontext TRIM relevant. Diese Zahl entspricht der kleinsten Speichermenge, welche das Gerät löschen kann. Die auf Ebene des Dateisystems verwendete Blockgröße sollte ein ganzzahliges Vielfaches von DISC-GRAN sein.

Ein weiterer schneller Test benutzt hdparm:

sudo hdparm -I /dev/sd? | grep -e TRIM -e Model 

Beispielausgabe:

	Model Number:       HGST HTS725032A7E635  OPAL              
	Model Number:       TS512GMTS430S                           
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM
	Model Number:       Samsung SSD 850 EVO 250GB               
	   *	Data Set Management TRIM supported (limit 8 blocks)

Hier wird jetzt die Samsung 850 EVO richtig beurteilt, aber das hilft leider nicht, wenn der zwischengeschaltete USB/SATA-Konverter nicht mitspielt.

Siehe auch Artikel SSD/TRIM/Testen.

Wird Batched Discard gestartet?¶

Dazu fragt man ab, ob der zuständige Timer läuft:

systemctl list-timers '*trim*' 

Beispielausgabe:

NEXT                          LEFT LAST                            PASSED UNIT         ACTIVATES     
Mon 2024-10-28 00:17:36 CET 6 days Mon 2024-10-21 07:36:43 CEST 47min ago fstrim.timer fstrim.service

Arbeitet Batched Discard auch richtig?¶

Hierzu fragt man aus dem Systemlog die Meldungen ab:

journalctl -u fstrim.service 

Beispielausgabe 1:

Okt 07 09:53:26 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Okt 07 09:53:26 Maria systemd[1]: fstrim.service: Deactivated successfully.
Okt 07 09:53:26 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.
-- Boot 70c2d21dffad4e9a969b0105b386d780 --
Okt 14 07:12:42 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Okt 14 07:12:43 Maria systemd[1]: fstrim.service: Deactivated successfully.
Okt 14 07:12:43 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.
-- Boot e2303c96212f49dcbdf799d0a5e9de4f --
Okt 21 07:36:43 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Okt 21 07:36:43 Maria systemd[1]: fstrim.service: Deactivated successfully.
Okt 21 07:36:43 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.

Im Beispiel wird die Unit fstrim.service wie erwartet wöchentlich gestartet und läuft auch fehlerfrei, macht aber gar nichts – was daran liegt, dass die in diesem System verbauten Geräte TRIM nicht beherrschen.

Beispielausgabe 2:

Okt 28 06:44:16 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Okt 28 06:44:20 Maria fstrim[37403]: /mnt/Daten-A: 27,1 GiB (29050531840 Bytes) auf /dev/sdb10 getrimmt
Okt 28 06:44:20 Maria fstrim[37403]: /: 6,7 GiB (7185223680 Bytes) auf /dev/sdb3 getrimmt
Okt 28 06:44:20 Maria systemd[1]: fstrim.service: Deactivated successfully.
Okt 28 06:44:20 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.

Hier wurden nun Bereiche mit veralteten Daten in Summe von 33,8 GiB bereinigt und können wieder belegt werden.

Sollte ich Batched Discard verwenden?¶

In den meisten Fällen: Ja. Allerdings bearbeitet die bereits im Betriebssystem eingebaute Unit in der Regel nur Dateisysteme auf internen Datenträgern mit Einträgen in der Datei fstab^[4].

In der Praxis muss man ggf. selbst optimieren:

• Ausführungszeit genauer festlegen auf Zeiträume, in denen mit hoher Wahrscheinlichkeit der Rechner läuft, aber nur wenig genutzt wird.

• Die nur temporär angeschlossenen Geräte wie beispielsweise USB-SSDs einbeziehen. → Externe SSD

Sollte ich Online Discard verwenden?¶

In den meisten Fällen: Nein, außer man ist Experte und "Batched Discard" liefert unbefriedigende Resultate.

Bei Dateisystemen vom Typ Btrfs sollte man überlegen, ob man das standardmäßig eingeschaltete discard nicht lieber ausschalten möchte, bei ext4 ist es nicht aktiviert.

Externe SSD¶

Externe Geräte wie beispielsweise USB-SSDs, die wechselweise an mehrere Rechner oder nur temporär angeschlossen werden, werden nicht automatisch getrimmt, da ihnen in der Regel kein Einbindepunkt über die Datei fstab zugewiesen wird. Man kann sie natürlich in diese Datei aufnehmen, muss aber berücksichtigen, dass automatisches TRIM über die Systemd-Unit nur dann erfolgt, wenn sie zum Zeitpumkt des Laufs tatsächlich angeschlossen und eingebunden sind.

Auf jeden Fall sollte man sich ein Konzept überlegen, wie man derartige Geräte behandeln möchte. Grundsätzlich funktionieren natürlich auch bei externen Geräten alle vorgestellten Methoden, aber man muss selber über deren für die eigenen Bedürfnisse zweckmäßige Aktivierung nachdenken und das eigene Konzept umsetzen.

Beispiel für ein solches Konzept:

• Man kauft eine SSD und ein Gehäuse; beide Komponenten dürfen kein Problem mit "Online Discard" machen.

• Man verwendet LUKS Version 2 für die Verschlüsselung.

• Man formatiert das virtuelle Blockgerät SDA99 mit dem Dateisystem ext4.

• Man definiert die Option discard als Standardversion für dieses Dateisystem, wie oben als zweite Methode beschrieben. Damit erspart man sich Eingriffe die Datei /etc/fstab^[4] auf allen Systemen, an die man diese tranportable SSD anschließen will.

• Man speichert die Option allow_discards permanent im LUKS2-Header. Dazu mun man die SSD nur ein einziges Mal nach manuellem Aufschließen und Einbinden neu konfigurieren:

  sudo cryptsetup --allow-discards --persistent refresh SDA99 

Nach dieser einmaligen Vorbereitung muss man zukünftig nur noch die Passphrase eingeben und kann für dieses Gerät das Thema TRIM vergessen.

(Siehe: Enable TRIM on external LUKS encrypted drive 🇬🇧)