SSD unter Linux trimmen: fstrim.timer prüfen, manuell trimmen, Cronjob ohne Anacron

Unter Ubuntu, Linux Mint, Debian und Fedora trimmt das System Deine SSD in der Regel automatisch: Der systemd-Timer fstrim.timer startet fstrim einmal pro Woche. Du musst nur prüfen, ob er läuft. Von Hand trimmst Du mit sudo fstrim -av. Einen eigenen Cronjob brauchst Du auf Systemen ohne systemd, etwa unter Devuan, und der klappt auch ohne Anacron.

SSD-Massenspeicher sind eine wunderbare Sache. Sie verleihen Notebooks und Rechnern nicht nur einen Turbo, sondern sind auch weniger anfällig gegen Schock und sind unter Umständen sogar noch stromsparender als herkömmliche Festplatten.

Allerdings brauchen SSD-Speicher etwas Pflege. Das nennt man TRIM. Ich will mich da gar nicht lange über dieses Thema auslassen, weil es einen wunderbaren Artikel auf Deutsch im Wiki der Ubuntuusers gibt. Nur kurz die Erklärung, was TRIM eigentlich macht.

TRIM markiert ungenutzte oder ungültige Datenblöcke und gibt diese zur späteren Wiederbeschreibung frei. Nach dem Löschen von Dateien wird dem Laufwerk mitgeteilt, dass die davon betroffenen Blöcke ungültig sind. Die Inhalte werden somit nicht mehr mitgeschrieben. Das kann die Schreibzugriffe beschleunigen und die Abnutzung verringern. Wie stark, hängt von der Firmware der SSD ab.

Derzeit gilt, dass SSD und das Dateisystem ext4 eine extrem sinnvolle Kombination ist. Aber nicht nur aus diesem Grund habe ich mich persönlich auch für ext4 für die SSD entschieden. Es ist einfach bei vielen Linux-Distributionen das Standard-Dateisystem, auch wenn Fedora bei Desktop-Installationen seit Version 33 auf Btrfs setzt.

TRIM-Unterstützung prüfen und fstrim manuell starten

Unter Linux heißt der Befehl fstrim und man kann ihn als root manuell abfeuern. Allerdings sollte man zunächst herausfinden, ob die SSD TRIM auch unterstützt. Bei einer SATA-SSD geht das so und in meinem Fall kann die SSD damit umgehen:

sudo hdparm -I /dev/sda | grep -i TRIM

Das Werkzeug hdparm fragt nur SATA- und IDE-Laufwerke ab. Bei NVMe-SSDs und bei SSDs im USB-Gehäuse nimmst Du lsblk:

lsblk --discard

Stehen in den Spalten DISC-GRAN und DISC-MAX Werte größer als 0, nimmt das Gerät TRIM-Befehle an. Zeigt eine SSD im USB-Gehäuse dort 0, reicht oft der USB-SATA-Adapter TRIM nicht durch, obwohl die SSD selbst es kann.

Danach kann ich den Befehl nun manuell abfeuern:

sudo fstrim -v /

Das Ergebnis sieht dann so aus:

Mit -a trimmst Du alle eingehängten Dateisysteme auf Geräten, die TRIM unterstützen, also auch eine eigene /home-Partition:

sudo fstrim -av

Die gemeldete Menge ist ein Höchstwert. Bei jedem Lauf meldet fstrim alle freien Blöcke erneut, tatsächlich verwirft die SSD nur Bereiche, die seit dem letzten Lauf beschrieben wurden.

So weit so gut. Aber ich will das nicht immer manuell machen und außerdem vergisst man das auch dann und wann. Man könnte nun das Dateisystem so einbinden, dass nach entsprechenden Datei-Operationen diese TRIM-Operationen automatisch ausgeführt werden. Das Ganze nennt sich dann Online Discard. Diese Methode ist aber umstritten und es wird behauptet, dass es zu enormen Performance-Einbrüchen führen kann. Also möchte ich lieber ein Batched Discard einsetzen, also das manuelle Ausführen des Befehls. Ich lasse mir das manuelle allerdings durch einen Cronjob abnehmen.

Heute ist das Bild differenzierter. Bei SATA-Geräten vor SATA 3.1 lassen sich TRIM-Befehle nicht in die Warteschlange einreihen. Mit discard hängt so ein System dann immer wieder kurz. Die Handbuchseite von fstrim hält einen Lauf pro Woche für die meisten Desktop- und Server-Systeme für ausreichend. Bei ext4 bleibt discard aus, solange Du es nicht in die /etc/fstab schreibst. Btrfs schaltet seit Kernel 6.2 auf SSDs, die das unterstützen, von sich aus discard=async ein. Das sammelt freie Blöcke und meldet sie gebündelt, was kaum bremst.

fstrim.timer: Ubuntu, Mint, Debian und Fedora trimmen automatisch

Den Cronjob weiter unten brauchst Du auf aktuellen Distributionen meist nicht mehr. Das Paket util-linux bringt die systemd-Units fstrim.service und fstrim.timer mit. Der Timer startet fstrim einmal pro Woche für alle Dateisysteme aus der /etc/fstab, deren Gerät TRIM kann. War der Rechner zum geplanten Zeitpunkt aus, holt systemd den Lauf nach dem nächsten Start nach. Anacron ist dafür nicht nötig.

Ubuntu trimmt SSDs seit Version 14.04 automatisch, anfangs noch per wöchentlichem Cronjob (automatisches TRIM in Ubuntu 14.04). Seit Ubuntu 18.04 erledigt das der Timer, Linux Mint hat ihn seit Version 19. Fedora aktiviert ihn seit Version 32, Debian seit Debian 11 bei Neuinstallationen. Auf Debian-Systemen, die per Upgrade von einer älteren Version kommen, kann er fehlen. So prüfst Du den Status:

systemctl status fstrim.timer
systemctl list-timers fstrim.timer

Steht in der Ausgabe enabled und active (waiting), ist alles erledigt. Die Zeile mit list-timers zeigt Dir den nächsten und den letzten Lauf. Was fstrim dabei getrimmt hat, steht im Journal:

journalctl -u fstrim.service

Ist der Timer aus, schaltest Du ihn so ein:

sudo systemctl enable --now fstrim.timer

Bei NVMe-SSDs arbeiten fstrim und der Timer genauso wie bei SATA-SSDs. Externe SSDs am USB-Port trimmt der Timer nur, wenn sie in der /etc/fstab stehen und beim Lauf eingehängt sind.

Eigene TRIM-Wege

Auf Systemen ohne systemd, etwa Devuan, gibt es keinen fstrim.timer. Dort ist ein Cronjob weiterhin der richtige Weg. Läuft bei Dir fstrim.timer und Du willst trotzdem selbst trimmen, schalte den Timer vorher ab, damit nicht zwei Mechanismen trimmen:

sudo systemctl disable --now fstrim.timer

Ein TRIM per Cron wurde damals zwar ebenfalls im Wiki-Artikel beschrieben, allerdings passte mir das nicht ganz. Der Autor beschrieb, wie man ein Shell-Script über cron.daily oder cron.weekly einstellt, welches den TRIM-Prozess täglich oder wöchentlich anstößt. Das kann man machen, wenn ein Rechner 24×7 im Einsatz oder eben Anacron installiert ist.

In meinem Fall würde die im Wiki beschriebene Methode auch funktionieren, weil Anacron per Standard installiert ist. Ist es aber nicht vorhanden, funktioniert es so nicht. Deswegen habe ich mir ein System über normale Cronjobs ausgedacht, das auf jedem System mit Cron funktioniert, unabhängig von Anacron. Manchmal bin ich da lieber etwas konservativ und nehme die Methode, die sicher funktioniert, auch wenn ich ein klein wenig mehr Arbeit in das Script investieren muss. Never change a running system … 🙂

Also schnappe ich mir das Script aus dem Ubuntu-Wiki und passe es für meine Bedürfnisse an:

#!/bin/sh
DATE=$(/bin/date +%Y%m%d)
CHECK_DATE_DIR="/root"
DATE_FILE="$CHECK_DATE_DIR/$DATE.date"
LOG=/var/log/batched_discard.log
if [ ! -f $DATE_FILE ]; then
rm -f $CHECK_DATE_DIR/*.date
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
/usr/bin/touch $DATE_FILE
fi

Was macht das Script?

Im Prinzip nicht viel. Aber anstatt nur / zu trimmen frage ich das heutige Datum noch ab. Wird das Script erstmalig ausgeführt, schreibt das Programm einen Zeitstempel mit der Endung .date in das Verzeichnis /root. Bei jedem weiteren Durchlauf wird auf diesen Zeitstempel geprüft. Ist das heutige Datum schon vorhanden, wird der fstrim-Befehl über die if-Abfrage nicht mehr ausgeführt. Das ! negiert die Prüfung und was innerhalb der if-Abfrage steht wird nur dann ausgeführt, wenn der Zeitstempel von heute nicht vorhanden ist. Somit kann ich fstrim also nur einmal täglich aufrufen. Ebenso schreibt das Script nichts mehr in die Log-Datei.

Hast Du weitere Partitionen wie /home, ersetzt Du im Script fstrim -v / durch fstrim -av.

Der Cronjob

Nun muss ich nur noch einen Cronjob anlegen. Ich lasse diesen mal alle 30 Minuten aufrufen. Damit habe ich eine hohe Chance, dass der Befehl einmal täglich ausgeführt wird. Sollte fstrim schon gelaufen sein, wird es ja übersprungen. Das Script habe ich batched_discard.sh genannt, ebenfalls nach /root kopiert und via chmod 755 batched_discard.sh ausführbar gemacht. Nun lege ich den Cronjob an und rufe als root den Befehl crontab -e auf. Am Ende (wobei das egal ist) füge ich nun folgende Zeile ein:

*/30 * * * * /root/batched_discard.sh > /dev/null 2>&1

Somit wird mein Script alle 30 Minuten aufgerufen. Das > /dev/null 2>&1 am Ende der Zeile verwirft alle Ausgaben des Aufrufs. Sonst verschickt Cron sie als Mail an den Besitzer der Crontab. Das Protokoll von fstrim landet trotzdem in /var/log/batched_discard.log. Nun wird fstrim auch mit hoher Wahrscheinlichkeit einmal am Tag ausgeführt.

Wie gesagt: Mit Anacron geht das natürlich auch. Aber ich halte mich persönlich lieber an gewohnte Sachen, von denen ich weiß, dass diese wirklich überall funktionieren.

TRIM bei LUKS-Verschlüsselung und LVM

Bei einer mit LUKS verschlüsselten SSD reicht dm-crypt TRIM-Befehle nur weiter, wenn Du das erlaubst. Standardmäßig ist das aus: An den getrimmten Blöcken ließe sich ablesen, welche Bereiche frei sind, und daraus etwa auf Dateisystem und belegten Platz schließen. Der Debian-Installer setzt die Freigabe seit Debian 10 bei neuen verschlüsselten Installationen selbst, Fedora seit Version 27. Ob TRIM durchkommt, zeigt:

sudo dmsetup table

Steht in der Zeile des verschlüsselten Geräts am Ende allow_discards, ist alles in Ordnung. Fehlt der Eintrag, ergänzt Du in der /etc/crypttab in der Zeile des Geräts hinter luks die Option discard, also luks,discard. Liegt das Root-Dateisystem auf dem verschlüsselten Gerät, baust Du unter Debian, Ubuntu und Mint danach das initramfs neu:

sudo update-initramfs -u -k all

Bei LUKS2 kannst Du die Freigabe auch im LUKS-Header speichern. Ersetze sda3_crypt durch den Namen Deines geöffneten Geräts:

sudo cryptsetup --allow-discards --persistent refresh sda3_crypt

LVM reicht TRIM aus dem Dateisystem ohnehin an die SSD weiter. Die Option issue_discards in /etc/lvm/lvm.conf brauchst Du dafür nicht. Sie gilt nur für Platz, den LVM selbst freigibt, etwa bei lvremove oder lvreduce. Ist sie an, lassen sich versehentlich gelöschte Volumes nicht mehr mit vgcfgrestore zurückholen.

Muss man die Swap- oder Auslagerungs-Datei trimmen?

Eine Swap-Partition hat keinen Einhängepunkt, fstrim.timer lässt sie deshalb aus. TRIM für Swap schaltest Du in der /etc/fstab mit der Option discard in der Swap-Zeile ein oder beim Aufruf mit swapon –discard. Mit discard=once verwirft swapon den ganzen Bereich einmal beim Aktivieren, mit discard=pages meldet der Kernel frei werdende Seiten laufend. Das kann bei manchen SSDs die Leistung verbessern, oft bringt es aber nichts. Ubuntu legt bei Neuinstallationen seit Version 17.04 meist eine Swap-Datei statt einer Swap-Partition an.

Grundsätzlich sollte man sich die Frage stellen, ob man überhaupt einen Swap-Space braucht. Viele Systeme hatten schon damals mindestens 4 GByte Arbeitsspeicher, und auf meiner Reise-Maschine brauchte ich den Swap-Space nicht. Sollte im Rechner auch noch eine herkömmliche Festplatte zur Verfügung stehen, sollte man den Swap-Space lieber auf diese legen.

Als Ausnahme gilt, wenn man auf dem System die Hibernate-Funktion einsetzt. Dann empfiehlt es sich aber, die so genannte Swappiness anzupassen. Der Swap-Artikel im Arch-Wiki nennt 1 als kleinsten sinnvollen Wert für die Swappiness und 50 als Vorschlag für vfs_cache_pressure auf Desktops. Dauerhaft trägst Du die Zeilen in eine eigene Datei wie /etc/sysctl.d/99-swappiness.conf ein, denn Debian 13 liest /etc/sysctl.conf nicht mehr.

vm.swappiness=1
vm.vfs_cache_pressure=50

Damit wird der Wert von Swappiness auf 1 gesetzt (Standard ist 60). Der Kernel gibt dann bevorzugt Datei-Cache frei, statt Programmspeicher auszulagern. Swap nutzt er trotzdem, wenn der Arbeitsspeicher knapp wird. Wer den Effekt sofort haben möchte, kann das als root mit dem Befehl echo 1 > /proc/sys/vm/swappiness erreichen.

Noch mehr Platz auf der SSD schaffst Du, wenn Du alte Linux-Kernel löschst. Ob sich bei einem älteren Notebook eine SSD lohnt, steht unter SSD nachrüsten oder neues Notebook kaufen.

Aktualisiert am 13.10.2026 von Henry. Fakten geprüft.