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.
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 Aritkel SSD/Begriffsdefinitionen (Abschnitt „TRIM“). Hallo, damit du TRIM unter Ubuntu 10.04 nutzen kannst, musst du den Kernel ab 2.6.33 nachinstallieren aus den Repos. Diese sind in den Repos enthalten. Um die TRIM-Funktion nutzen zu können, müssen einige Mountoptionen in /etc/fstab gesetzt werden. Einzelheiten dazu stehen in den Abschnitten TRIM mit ext4 respektive TRIM mit btrfs. Des Weiteren muss die SSD natürlich die TRIM-Funktion unterstützen, was aber bei aktuellen bzw neu gekauften SSD so gut wie immer der Fall ist. Können der Kernel oder die SSD kein TRIM, so hilft der Abschnitt Manueller TRIM weiter.
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) zu setzen, andere führen TRIM manuell aus (wiper.sh), 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.
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
Die Ausgabe sieht dann in etwa wie folgt aus. Der Stern (*
) zeigt an, dass die Option verfügbar ist.
* Data Set Management TRIM supported * Deterministic read data after TRIM
Testen des automatischen TRIM¶
Man kann 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
Als Ausgabe erhält man wieder:
/dev/sda: reading sector 57438208: succeeded
Bei erfolgreicher automatischem TRIM jedoch dieses Mal gefolgt von einer langen Liste vierstelliger Nullen statt der vorher kryptischen Zahlen/Buchstaben, was bedeutet, dass das automatische TRIM funktioniert.
TRIM mit 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).
Um die TRIM-Funktion 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 Optionen discard
und noatime
(ersetzt das standardmäßige relatime
):
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 jedesmal bei einem Dateizugriff die Inodetabelle aktualisiert werden muss. Nach einem Neustart des Rechners sind beide Optionen aktiv.
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.
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
.
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 den Mountpoint -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 ssd,noatime,errors=remount-ro 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 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)
discard
(ab Kernel 2.6.32)Abgrenzungen werden en masse zur „transaction commit time“ getrimmt (Extents are trimmed in bulk at transaction commit time)
Einzelne Hardware trimmt sehr langsam (Some hardware trims very slowly today)
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)¶
Zum manuellen Trimmen nutzt man mit Linux am besten (externe) Skripte, welche die Trimmung der SSD durchführen.
Achtung!
Wichtig zu wissen ist, dass man diese Skripte 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:
hdparm – Beinhaltet das Skript wiper.sh für die Shell (Zur Downloadübersicht ⮷)
DiskTrim – Ein grafisches Tool, welches das Skript wiper.sh nutzt, um SSD zu trimmen (Zur Downloadübersicht ⮷)
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.
Links¶
Weiterführende Informationen zu TRIM:
Informationen zu manuellem TRIM (wiper.sh und DiskTRIM):
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
madeo.co.uk: Intel X25-M Gen2 on linux – migrating to btrfs on kernel 2.6.33 🇬🇧