ubuntuusers.de

Du betrachtest eine alte Revision dieser Wikiseite.

TRIM

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.

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.

Wiki/Icons/SSD.png 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 die SSD als auch der Kernel TRIM unterstützen. Dies zeigen die beiden nachfolgenden Tests Testen des TRIM der SSD und Testen des TRIM des Kernels.

Hinweis:

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.

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 zugeschnittete 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 Journaling 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, hat man das Journaling abgeschaltet, die Mountoption data=writeback in /etc/fstab eintragen. Im Abschnitt Links gibt es eine ausführlichere Beschreibung der Option data=writeback.

Testen des TRIM der SSD

Um zu überprüfen, ob eine SSD die TRIM-Funktion unterstützt, nutzt man den folgenden Befehl in einem Terminal [1] mit Root-Rechten [2] :

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

Im Positivfall enthält die Ausgabe eine der folgenden Zeilen:

	   *	Data Set Management TRIM supported
	   *	Data Set Management TRIM supported (limit N blocks)
           *    Data Set Management TRIM supported (limit unknown)

Der Stern (*) zeigt an, dass die Option verfügbar ist.

Zu beachten ist außerdem, dass es mehrere Typen von SSDs gibt, die sich darin unterscheiden, welche Daten für per TRIM freigebene Datenblöcke zurückgeliefert werden. Zu erkennen ist der Typ an einer zusätzlichen Ausgabezeile:

Typ 1 – liefert beliebige Daten zurück, nicht jedoch die Ausgangsdaten vor TRIM:

	   *	Deterministic read data after TRIM

Typ 2 – liefert Nullen zurück:

	   *	Deterministic read ZEROs after TRIM

Typ 3 – keine zusätzliche Ausgabezeile, das Verhalten für freigegebene Datenblöcke ist undefiniert.

Testen des TRIM des Kernels

Nur für SSDs des oben beschriebenen Typ 2 kann man in einem Terminal [1] mit Root-Rechten [2] sehr einfach testen, ob der automatische TRIM (ab Kernel 2.6.33) funktioniert. Das folgende Verfahren zeigt, wie man vorgeht:

cd /									# man kann auch nach home wechseln, wenn es auf der SSD liegt
sudo dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct	# man braucht kein sudo, wenn home auch auf der SSD liegt 

Die Ausgabe zeigt in etwas das Folgende:

100+0 Datensätze ein
100+0 Datensätze aus
52428800 Bytes (52 MB) kopiert, 8,23889 s, 6,4 MB/s

Der nächste Befehl generiert Informationen zum eben erzeugten tempfile:

sudo hdparm --fibmap tempfile 

Das Ganze sieht wie folgt aus:

tempfile:
 filesystem blocksize 4096, begins at LBA 54528000; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0   57438208   57439231       1024
      524288   57469952   57477119       7168
     4194304   57632768   57673727      40960
    25165824   57722880   57755647      32768
    41943040   57968640   57989119      20480

Davon kopiert/merkt man sich die erste Nummer, die unter begin_LBA steht, da diese im nächsten Befehl gebraucht wird. In diesem Fall ist das die Nummer 57438208. Die nachfolgenden Befehle setzen voraus, dass die SSD unter /dev/sda zu finden ist.

sudo hdparm --read-sector 57438208 /dev/sda		# die Zahl 57438208 muss mit der eigenen ersetzt werden 

Man erhält daraufhin eine lange Liste vierstelliger Buchstaben und Zahlen. Wichtig ist die folgende Ausgabe:

/dev/sda:
reading sector 57438208: succeeded

Mit den nächsten beiden Befehlen löscht man das oben erzeugte tempfile und synct dann die SSD:

sudo rm tempfile
sync 

Auch nachdem man das tempfile gelöscht hat, sind die Sektoren der SSD noch nicht geleert. Man wartet nun einige Sekunden/Minuten und gibt dann zur Kontrolle erneut den obigen Befehl ein:

sudo hdparm --read-sector 57438208 /dev/sda		# die Zahl 57438208 muss mit der eigenen ersetzt werden 

Bei erfolgreichem automatischem TRIM erhält man als Ausgabe erneut

/dev/sda:
reading sector 57438208: succeeded

dieses Mal jedoch gefolgt von einer langen Liste vierstelliger Nullen (statt der vorher kryptischen Zahlen/Buchstaben). Dies bedeutet, dass das automatische TRIM funktioniert.

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 (empfohlen) – 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 (nicht empfohlen) – 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 discard eingeschaltet 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

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:

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 mit Festplattenverschlüsselung

Damit ein „Batched Discard“ auf einer mit dm_crypt (LUKS) verschlüsselten Festplatte funktioniert, benötigt man zusätzliche Bootparameter für den Kernel. Die Parameter lauten allow-discards und root_trim=yes und können bei Nutzung des GRUB 2-Bootloaders in der Datei /etc/default/grub unter der GRUB_CMDLINE-Option eingetragen werden.

sudo nano /etc/default/grub 

1
GRUB_CMDLINE_LINUX="allow-discards root_trim=yes"

Anschließend die GRUB-Konfiguration aktualisieren.

sudo update-grub 

Nach dem Neustart sollte der fstrim-Befehl tadellos funktionieren.

TRIM per Online Discard

Achtung!

Durch die per „Online Discard“ entstehenden zahlreichen TRIM-Befehle kann die Performance der SSD erheblich reduziert werden. Es finden sich Berichte, dass SSD durch „Online Discard“ unbenutzbar wurden.
Anwender sollten daher wenn möglich, „Online Discard“ in /etc/fstab deaktivieren und durch manuelles oder per Cronjob durchgeführtes „Batched Discard“ ersetzen.

Um die TRIM-Funktion „Online Discard“ nutzen zu können, mit deren Hilfe das Betriebssystem der SSD mitteilt, welche Datenbereiche nicht mehr benötigt werden und damit als gelöscht angesehen werden können, müssen einige Mountoptionen in der /etc/fstab gesetzt werden.

Man öffnet dazu mit Root-Rechten [2] einen Editor [3] und ergänzt in der Datei /etc/fstab [4] die bestehenden Zeilen mit den Optionen discard und noatime :

UUID=EIGENE_FESTPLATTE	/	ext4	 discard,noatime,errors=remount-ro	 0       1

Die Option discard sorgt dabei dafür, dass TRIM-Befehle vom ext4-Dateisystem an den Controller der SSD durchgereicht werden, wenn Blöcke frei werden. Diese Option muss manuell gesetzt werden, da sie zurzeit noch deaktiviert ist 🇬🇧 („…but it is off by default until sufficient testing has been done.“).

Die Option noatime sorgt dafür, dass durch die Nicht-Protokollierung von Zugriffszeiten die Festplattenaktivitäten reduziert werden, da nicht jedes mal bei einem Dateizugriff die Inodetabelle aktualisiert werden muss. Nach einem Neustart des Rechners sind beide Optionen aktiv.

TRIM mit Lucid Lynx (Kernel 2.6.32)

Der Standard-Kernel 2.6.32, der in der LTS-Version von Lucid Lynx seinen Dienst verrichtet, unterstützt den TRIM-Befehl nicht ("The current plan is that Ubuntu 10.04 will never receive TRIM support." siehe Trim support missing from Linux kernel).

Man sollte beim Einsatz einer SSD und Ubuntu 10.04 LTS auf einen Mainline-Kernel ausweichen – dieser sollte mindestens Kernel 2.6.33 oder besser 2.6.37 sein.

Exkurs: Mountoption relatime

Aktuelle Ubuntuversionen binden Laufwerke von Haus aus mit der Mountoption 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 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!

Btrfs ist nach wie vor in der Entwicklung! Man sollte es daher nicht auf Produktivsystemen einsetzen und, wenn man es zum Testen einsetzt, vorher Backups machen! Vor allem sollte man das Skript wiper.sh auf keinen Fall anwenden, wenn man btrfs nutzt (siehe Abschnitt Manueller TRIM (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).

Btrfs setzt automatisch die Mountoption -o ssd, sofern es eine SSD als Festplatte erkennt. Laut dem Btrfs-Wiki 🇬🇧 geschieht dies per Standard ab Kernel 2.6.31 (also ab Ubuntu 10.04 Lucid Lynx). Nichtsdestotrotz kann man die Datei /etc/fstab [4] manuell anpassen , so dass sie wie folgt aussieht:

UUID=EIGENE_FESTPLATTE	/	btrfs	 defaults,ssd,noatime,compress,subvol=@	 0       1

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_spread

    • Platziert 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.

Manueller TRIM (wiper.sh)

Seit Version 9.17 von hdparm (ab Maverick Meerkat) beinhaltet dieses das Skript wiper.sh. Dieses durchsucht das Dateisystem nach freien Bereichen und meldet diese dem Controller der SSD.

Achtung!

Beim Einsatz des Skripts kann es durch falschen Gebrauch oder einen Fehler des Skriptes sehr schnell zu Datenverlust kommen. Das Skript wiper.sh sollte daher nur in Ausnahmefällen und mit vorhandenen Backups durchgeführt werden.

Zum manuellen Trimmen nutzt man mit Linux am besten (externe) Skripte, welche die Trimmung der SSD durchführen (siehe TRIM per Batched Discard).

Achtung!

Wichtig zu wissen ist, dass man wiper.sh auf keinen Fall anwenden soll, wenn man das Dateisystem btrfs nutzt (siehe Abschnitt TRIM mit btrfs).

Hinweis!

Fremdsoftware kann das System gefährden.

Auf Sourceforge gibt es zwei Projekte, die sich mit diesem Thema beschäftigen. Beide nutzen das Skript wiper.sh:

Die Skripte müssen heruntergeladen und entpackt [5] werden. Danach startet man, hat man das Wiper-Skript heruntergeladen, wiper.sh aus dem beinhaltenden Ordner in einem Terminal [1] mit Root-Rechten [2] mit folgendem Befehl:

sudo ./wiper.sh --verbose --commit /dev/sda		## oder z. B. / oder /boot oder /dev/sda4 

Danach muss man die Abfrage mit y bestätigen:

wiper.sh: Linux SATA SSD TRIM utility, version 2.7, by Mark Lord.
Preparing for online TRIM of free space on /dev/sda (ext4 mounted read-write at /mnt/ubuntu).

This operation could silently destroy your data.  Are you sure (y/N)? y
Creating temporary file (9251416 KB).. 
Syncing disks.. 
Beginning TRIM operations..

/dev/sda:
trimming 18502832 sectors from 325 ranges
succeeded
Removing temporary file..
Syncing disks.. 
Done.

Das Skript kann eingehängte (mounted) ext4 und xfs schreiben und lesen sowie ein- und ausgehängte (mounted/unmounted) ext2, ext3, ext4, reiser3 und xfs lesen (siehe Grundlegende Merkmale der Dateisysteme). Es stellt eine Liste von freien Blocks des Dateisystems zusammen und übergibt diese an die Firmware der SSD. Laut opensuse.org-Wiki 🇬🇧 sollte man wiper.sh einmal die Woche ausführen. Weitere Informationen zum Gebrauch der Tools findet man in der beiliegenden Readme.txt sowie im Abschnitt Links.

Diese Revision wurde am 24. August 2012 22:07 von linrunner erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Hardware, System, ungetestet