SSD-Speicher unter Linux trimmen: fstrim und Cronjob – auch ohne Anacron machbar

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 muss man die SSD-Speicher etwas manuell pflegen. 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. Beim 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 beschleunigt nicht nur die Schreibzugriffe, sondern reduziert auch die Abnutzung.

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 Btrfs im Kommen ist.

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

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

Prüfen, ob TRIM unterstützt wird

Danach kann ich den Befehl nun manuell abfeuern: sudo fstrim -v / – das Ergebnis sieht dann so aus:

fstrim: manuell abgeschossen

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.

Eigene TRIM-Wege

Dies wird zwar ebenfalls im Wiki-Artikel beschrieben, allerdings passt mir das nicht ganz. Der Autor beschreibt, wie man eine 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.

Cronjobs

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 mit Sicherheit auf jedem System 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.

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 bewirkt, dass mein Log nicht mit den Cron-Ausgaben zugemüllt wird. Nun wir fstrim auch mit hoher Wahrscheinlichkeit einmal am Tag ausgeführt.

Cronjob für fstrim angelegt

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.

Muss man die Swap- oder Auslagerungs-Datei trimmen?

Hier sollte man sich zunächst die Frage stellen, ob man überhaupt einen Swap-Space braucht. Viele Systeme haben heutzutage mindestens 4 GByte Arbeitsspeicher und auf meiner Reise-Maschine brauche 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. Dieser Artikel aus dem Arch-Wiki empfiehlt folgende Zeilen in der Datei /etc/sysctl.conf anzufügen.

vm.swappiness=1
vm.vfs_cache_pressure=50

Damit wird der Wert von Swappiness auf 1 gesetzt und dem Kernel angewiesen, fast ausschließlich den Arbeitsspeicher zu verwenden. Wer den Effekt sofort haben möchte, kann das als root mit dem Befehl echo 1 > /proc/sys/vm/swappiness erreichen.