Nichts beschleunigt einen PC so nachhaltig wie der Umstieg auf eine SSD. Damit diese ihr volles Potenzial erreicht und möglichst lange lebt, gilt es, das Linux-System an einigen kritischen Stellen anzupassen.

Als LinuxUser 2011 zum ersten Mal die technischen Grundlagen von Solid State Disks unter Linux beleuchtete [1], lag der Preis pro GByte von SSDs bei etwa 2 Euro. Inzwischen kostet eine günstige SSD mit 240 GByte Speicherplatz etwa 90 Euro, pro GByte also in etwa 0,35 Cent – ein Sechstel des Preises von vor drei Jahren. Doch nicht nur beim Preis und der Kapazität ergaben sich in den letzten Jahren Änderungen, auch die Inbetriebnahme und Handhabung einer SSD fällt unter Linux inzwischen leichter.

Nach wie vor gibt es immer noch keine andere Einzelmaßnahme, die einen Rechner derart beschleunigt wie der Einbau einer SSD. Die Übertragungsraten einer solchen Disk liegen bis zu zehnmal höher als die einer Festplatte (Abbildung 1). Sinn macht der Austausch zuallererst für die Systempartition und das Home-Verzeichnis. Hierfür genügen normalerweise SSDs mit einer Größe zwischen 64 und 128 GByte – heute gar nicht mehr so teuer. Möchten Sie für die Datenablage eine größere SSD oder gar eine USB-SSD erwerben, müssen Sie jedoch nach wie vor tief in die Tasche greifen. Mit der nächsten Strukturverkleinerung auf 12 Nanometer dürften aber auch die Preise für große SSDs weiter nachgeben.

Abbildung 1: Die SSD vom Typ OCZ Vertex 3 liefert auch nach vier Jahren Betrieb immer noch im Schnitt 450 MByte/s.

In der Fortsetzung unseres ersten Artikels überprüfen wir, welche Änderungen am Linux-System auch heute noch erforderlich sind und wie Sie Ihre SSD optimal einrichten, damit diese möglichst lange, schnell und zuverlässig ihre Aufgabe verrichtet.

Ausrichten der Partitionen

Für eine maximale Geschwindigkeit ist besonders bei SSDs mit ihren Seitengrößen von 4096 oder 8192 Bytes wichtig, dass sich die Partitionen an sinnvollen Grenzen des Datenträgers ausrichten – im Fachjargon nennt sich die Ausrichtung Partition Alignment [2]. Beim herkömmlichen Partitionieren von HDDs begann eine Partition bei einer Sektorgröße von 512 Byte automatisch immer mit dem 64. Sektor. Heute arbeiten viele Festplatten und vor allem SSDs allerdings mit physischen Sektorgrößen von 4 und mehr KByte.

Richten Sie nun auf einer SSD eine Partition ein, die wie üblich bei Sektor 64 beginnt, formatieren diese dann aber mit einem Dateisystem mit einer Blockgröße von 4 KByte, dann passen die 4K-Dateisystem-Blöcke nicht in die 4- oder 8-KByte-Pages der SSD (Abbildung 2). Beim Speichern eines 4K-Dateisystem-Blocks müsste der Speichercontroller dann immer gleich in zwei Sektoren schreiben. Hinzu kommt, dass die emulierten 512-Byte-Blöcke erhalten bleiben müssen, was zu einem Read/Modify/Write-Modus führt. Dieser Versatz setzt sich fort und bremst die Platte maßgeblich aus. Messungen bei IBM belegten eine bis zu 25-fach schlechtere Schreibleistung bei kleinen Dateien.

Abbildung 2: Für optimale Schreib-Leseleistung sollten sich Partitionen an den Speicherseiten der SSD ausrichten.

Mussten Sie 2011 noch selbst für die korrekte Ausrichtung sorgen, indem Sie beispielsweise cfdisk entsprechende Werte übergaben, so erledigen heutzutage grafische Partitionierungswerkzeuge wie GParted die Aufgabe automatisch. Sie richten den Beginn der ersten Partition auf genau 1 MByte aus. Mit fdisk oder gdisk prüfen Sie die Partitionierung der SSD (Listing 1). Die Ausgabe zeigt die Architektur der gesamten Platte. In der letzten Zeile sehen Sie den Beginn der Partition auf Sektor 2048, was nach der Rechnung 2048 Sektoren * 512 Byte pro (logischem) Sektor gleich 1?048?576 Bytes gleich 1 MByte entspricht – für SSDs optimal ausgerichtet.

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Disk /dev/sda: 117231408 sectors, 55.9 GiB
Logical sector size: 512 bytes
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 117231374
Partitions will be aligned on 2048-sector boundaries
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       117229567   55.9 GiB    8300  Linux filesystem

TRIM dich fit

Herkömmliche Festplatten überschreiben fortwährend gelöschte Daten mit neuen Dateien. SSDs arbeiten aufgrund ihrer internen Struktur und des Speichermediums NAND-Flash [3] allerdings mit einem anderen Verfahren: Hier muss der NAND-Chip eine Datei erst gezielt löschen, bevor neue Daten den von ihr belegten Platz einnehmen dürfen.

Die kleinste beschreibbare Einheit einer SSD stellt eine Seite (“page”) dar. Die Steuereinheit des Speichers kann Seiten einzeln auslesen, fasst beim Schreiben jedoch die Seite zu Blöcken von 64 oder 128 Einheiten zusammen. Die kleinste löschbare Einheit stellt demnach solch einen “erasable block” mit einer Speichergröße von typischerweise 256 oder 512 KByte dar.

Um den belegten Platz einer gelöschten Datei nun auch wirklich vollständig zurückzuerhalten, muss der Controller zunächst alle noch benötigten Daten des Blocks in den Cache kopieren und dann den Block komplett löschen (Abbildung 3). Steuert der Controller nicht dagegen, resultiert daraus langfristig eine starke Fragmentierung der Daten und damit eine immer geringere Schreibleistung der SSD.

Abbildung 3: Schematische Darstellung eines Löschvorgangs von auf einer SSD gespeicherten Daten.

Zudem führt die durch das Umkopieren entstehende Vervielfältigung der Daten (die sogenannte Write Amplification [4]) dazu, dass der SSD irgendwann die freien Blöcke für das Speichern neuer Daten ausgehen würden (Abbildung 4). Daher arbeiten beim Löschen nicht mehr benötigter Daten zwei Mechanismen Hand in Hand: Auf der Seite des Laufwerks läuft die Garbage Collection [5] (Abbildung 5), auf Ebene des Dateisystems tritt der TRIM-Mechanismus [6] in Aktion. Beide Verfahren helfen dabei, zu löschende Daten zu markieren und bereits vor der neuerlichen Verwendung freizugeben.

Abbildung 4: Write Amplification aufgrund von Wear Leveling und Garbage Collection.

Ab Kernel 2.6.33 beherrscht Linux dazu den TRIM-Befehl. Er teilt dem Controller der SSD mit, welche Blöcke er aus der Sicht des Betriebssystems übergehen darf. Die Inhalte werden somit nicht mehr weiter mitgeschrieben, was die Schreibzugriffe auf das Laufwerk beschleunigt und zudem die Lebensdauer des Speichermediums erhöht. Dazu versucht der Speichercontroller, die Schreibzugriffe möglichst gleichmäßig über den Speicherbereich der SSD zu verteilen. Das Wear Leveling [7] gewährleistet eine gleichmäßige Abnutzung der Speicherblöcke und damit eine längere Lebensdauer der Platte (Abbildung 6).

Das Betriebssystem muss also dem Dateisystem mitteilen, wie und wann es TRIM-Befehle absetzen soll. Verwaltet der Logical Volume Manager (LVM) das Dateisystem und ist es obendrein mit LUKS/Dm-crypt verschlüsselt, so muss TRIM auf allen drei Ebenen agieren. Für die Verschlüsselungsebene geschieht dies in der Datei /etc/crypttab, die die Option discard enthalten muss (Listing 2).

# <target name>  <source device>      <key file>  <options>
sda1_crypt       /dev/sda1  none        luks,discard

In der LVM-Konfiguration schalten Sie die TRIM-Funktion scharf, indem Sie das Trimmen im Abschnitt Devices der Datei /etc/lvm/lvm.conf mit dem Eintrag issue_discards = 1 aktivieren. Für das Dateisystem – sowohl Ext4 als auch Btrfs eignen sich gut für SSDs – gibt es zwei Arten, das Trimmen einzusetzen: Online Discard und Batched Discard. Beim Online Discard fügen Sie für das jeweilige Gerät die Mount-Option discard in die Datei /etc/fstab ein (Listing 3).

UUID=uuid-nummer  /  ext4  defaults,noatime,discard,errors=remount-ro  0  1

Neben discard kommt es auch auf die Mount-Option noatime an. Linux speichert mit der atime von Haus aus die Zeit des letzten Dateizugriffs [8]. Dadurch entsteht bei jedem Lesevorgang auch wieder ein Schreibvorgang. Für die Lebensdauer der SSD wäre dieses Verfahren alles andere als zuträglich, daher sollte die SSD mit der Mount-Option noatime das Protokollieren ganz lassen. Alternativ bietet es sich an, mittels der Option relatime die Zugriffszeit nur dann zu speichern, wenn der letzte Zugriff vor der letzten Änderung der Datei stattfand.

Für dem kommenden Entwicklungszweig 3.19 des Linux-Kernels steht mit Lazytime [9] eine weitere Mount-Methode auf dem Plan. Diese speichert die Zugriffszeiten im Arbeitsspeicher und sichert sie nur dann auf die Platte, wenn es im selben Zug auch wichtigere Daten zu sichern gibt. Lazytime soll sich in Zukunft als Standard für Ext4-Dateisysteme etablieren.

Den im Internet weit verbreiteten “Tipp”, das Journaling bei Ext3/4-Partitionen auf SSDs abzuschalten, ordnet der Entwickler des Ext-Dateisystems Theodore T’so ins Land der Mythen ein. Er empfiehlt, das Journaling aktiviert zu lassen, um die Gefahr von Datenverlusten zu reduzieren [10].

Discard: Online oder Batched?

Zurück zu Online Discard: Die Mount-Option discard in /etc/fstab bewirkt bei jedem Löschen von Daten das Auslösen des TRIM-Befehls und somit einen Kopier- und Löschvorgang auf der SSD. Dieser braucht Zeit und bewirkt viele Schreibzugriffe, die die Lebensdauer der NAND-Chips der SSD verringern. Das gilt besonders bei Mainboards mit SATA-Chips vor Revision 3.1 und SSDs, die kein Queued TRIM unterstützen, das mit Kernel 3.12 eingeführt wurde [11].

Beim Einsatz von Batched Discard bestimmen Sie selbst, wann Sie mit dem Löschvermerk markierte Dateien physikalisch entfernen. Dabei kommt der Befehl fstrim aus dem Paket util-linux zum Einsatz (Listing 4). Die Option -v steht hierbei für “verbose” und sorgt für die Ausgabe der getrimmten Datenmenge. Falls Sie Fstrim testen möchten und bisher discard in der Datei Fstab verwenden, dann entfernen Sie die Option aus der Konfigurationsdatei, starten den Rechner neu und löschen eine Reihe von Dateien.

$ sudo fstrim -v /
/: 6,3 GiB (6764573482 bytes) trimmed
$ sudo fstrim -v /home
/home: 1,1 GiB (1155702784 bytes) trimmed

Da das Trimmen auch immer Schreibaktionen auslöst, führen Sie den Befehl am besten nicht allzu oft aus. Überlassen Sie es am besten gleich einem Cronjob [12], die SSD zu trimmen. So müssen Sie nicht auf Komfort verzichten, erzeugen aber wesentlich weniger Schreibzugriffe. Canonical hat den Vorgang mit Ubuntu 14.10 bereits automatisiert und führt ein wöchentliches TRIM durch, sofern das entsprechende Skript /etc/cron.weekly/fstrim eine SSD im System entdeckt.

#!/bin/sh
for fs in $(lsblk -o MOUNTPOINT,DISC-MAX,FSTYPE | grep -E '^/.* [1-9]+.* ' | awk '{print $1}'); do fstrim "$fs"; done

Ein solches Skript lässt sich aber auch schnell selbst anlegen. Das Beispiel aus Listing 5 wertet die Kernelfunktion discard_max_bytes aus. Gibt diese eine Null zurück, handelt es sich beim geprüften Speichermedium nicht um eine SSD; andernfalls führt das Skript das Kommando fstrim aus. Soll einmal täglich oder wöchentlich automatisch ein Discard stattfinden, dann legen Sie einen entsprechenden Cronjob an. Läuft der Rechner nicht ständig, nutzen Sie alternativ am besten Anacron: Ist der Rechner zum vorgesehenen Zeitpunkt nicht eingeschaltet, holt es den Auftrag nach, sobald der Rechner wieder läuft.

Die Verwendung von Batched Discard bietet noch weitere Vorteile. Kommt auf dem System etwa ein LVM oder LUKS zum Einsatz, und Discard wurde dafür nicht korrekt konfiguriert, dann gibt der Aufruf des Fstrim-Befehls einen Fehler aus. Die entsprechende Mount-Option in der Fstab dagegen würde dies “schweigend” hinnehmen, irgendwann liefe daher die Festplatte voll. Zudem lässt sich eine versehentlich gelöschte Datei mit den entsprechenden Werkzeugen wiederherstellen, solange das Trim-Skript noch nicht ausgeführt wurde. Steht discard als Mount-Option in der Fstab, gehen gelöschte Dateien dagegen unwiederbringlich verloren.

Liegt neben den Datenpartitionen auch der Swap-Speicher auf der SSD, dann sollten Sie auch hier auf ein korrektes Trimmen achten. Online Discard kann allerdings auch bei diesem Partitionstyp zu Leistungseinbußen führen. Seit Kernel 2.6.36 ist TRIM auf Swap-Partitionen daher optional, Sie müssen es manuell über die Swapon-Option --discard oder über die Fstab und die Mount-Option discard aktivieren [13]. Unabhängig davon führt Swapon beim Einbinden des Swap-Speichers einen Discard aus – das sollte für normale Rechner, die nur ab und an Speicher in den Swap auslagern, vollkommen ausreichen.

Schreibzyklen minimieren

Indem Sie unnötige Schreibzyklen vermeiden, helfen einige zusätzliche Maßnahmen dabei, das Leben der SSD zu verlängern. Dazu lagern Sie zum Beispiel Teile des Dateisystems mit Tmpfs [14] in den Arbeitsspeicher aus.

Sinn macht dies in jedem Fall für Verzeichnisse wie /tmp, /var/spool, /var/tmp sowie unter Umständen auch /var/log. Bei Letzterem müssen Sie entscheiden, ob Sie persistente Logs brauchen oder die Log-Dateien mit dem Herunterfahren des Rechners verloren gehen dürfen. Um die entsprechenden Verzeichnisse als tmpfs einzuhängen, fügen Sie die Einträge aus Listing 6 am Ende der Datei /etc/fstab an.

none /tmp tmpfs defaults,noatime,mode=1777 0 0
none /var/tmp tmpfs defaults,noatime 0 0
none /var/log tmpfs defaults,noatime 0 0
none /var/spool tmpfs defaults,noatime 0 0

Auch der Browser-Cache verursacht über die Zeit viele Schreibzyklen, weswegen Sie ihn ebenfalls in den Arbeitsspeicher auslagern sollten. Dafür bietet sich das Verzeichnis /run/user an, das von Haus aus im RAM liegt. In Firefox oder Iceweasel geben Sie dazu about:config in die Adresszeile ein und bestätigen die Sicherheitsabfrage.

Klicken Sie nun mit der rechten Maustaste an eine beliebige Stelle der Liste und erzeugen Sie über das Kontextmenü Neu | String einen neuen Eintrag. Als Namen geben Sie browser.cache.disk.parent_directory ein, der Inhalt des neuen Eintrags sollte /run/user/1000/firefox-cache lauten. Passen Sie dabei die 1000 an die User-ID an, die Ihnen der Befehl id -u auf dem System ausgibt. Nach einem Neustart des Browsers schreibt dieser nun seine temporären Daten in den Hauptspeicher.

Bei Chrome oder Chromium müssen Sie ein wenig anders vorgehen: Hier bearbeiten Sie mit den Dateien chrome.desktop, google-chrome.desktop oder chromium.desktop aus dem Verzeichnis /usr/share/applications/ den Startmenü-Eintrag des Browsers. In der Exec-Zeile fügen Sie mit einem mit Root-Rechten gestarteten Editor über die Option -disk-cache-dir=/run/user/$UID/chrome-cache das zu nutzende Cache-Verzeichnis ein (Listing 7). Ab dem nächsten Start von Chrome legt der Browser seine Daten im Hauptspeicher ab.

[...]
# Exec=/usr/bin/google-chrome-stable %U
Exec=/usr/bin/google-chrome-stable -disk-cache-dir=/run/user/$UID/chrome-cache %U
[...]

Das nötige Unterverzeichnis in /run/user/ legen die Browser dabei von alleine an. Das Prinzip lässt sich meist auch auf andere Browser übertragen. Nutzen Sie das System allerdings über lange Zeiträume ohne Neustart, dann sollten Sie auf den Füllstand des Arbeitsspeichers achten.

Den Takt vorgeben

Das Lesen und Schreiben von Daten auf Festplatten ist im Vergleich zu Zugriffen auf den Arbeitsspeicher eine quälend langsame Angelegenheit. Schon alleine das Ausrichten der Schreib/Leseköpfe auf den Magnetscheiben dauert mehrere Millisekunden. Das System braucht daher intelligente Verfahren, um die Zugriffszeiten so stark wie möglich zu reduzieren und Zugriffe auf die Platte so gut wie möglich zu optimieren.

Dafür ist im Linux-Kernel der I/O-Scheduler verantwortlich. Er kombiniert und sortiert Dateizugriffe so, dass die Köpfe der Festplatte sich möglichst wenig bewegen müssen. Der meist im Kernel standardmäßig eingestellte Completely-Fair-Queueing-Scheduler (CFQ) arbeitet nun aber für SSDs nicht optimal. Mit den Schedulern Deadline oder NOOP lassen sich auf einfache Weise zwischen 5 und 10 MByte/s mehr Transferrate aus der SSD kitzeln.

Den aktuell genutzten Scheduler lesen Sie für die erste Disk /dev/sda aus der Datei /sys/block/sda/queue/scheduler aus (Listing 8, erste Zeile). Der Scheduler lässt sich ohne die Notwendigkeit eines Neustarts ändern (Zeile 3). Allerdings übersteht diese Einstellung andererseits einen Neustart nicht.

$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
$ sudo tee /sys/block/sda/queue/scheduler <<< deadline
$ cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

Den gewünschten Taktgeber richten Sie am besten über Udev ein. Starten Sie dafür mit Root-Rechten einen Editor und speichern Sie den Inhalt aus Listing 9 in der Datei 60-schedulers.rules unter /etc/udev/rules.d/ ab. Udev erkennt anhand des Attributs queue/rotational, ob es sich um eine herkömmliche Festplatte oder eben eine SSD handelt und setzt dann automatisch den gewünschten Scheduler.

# fuer Solid State Drives : Aktiviere Deadline fuer SSDs
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Kernel 3.17 bringt als Neuerung für via SATA angeschlossene SSDs einen Mechanismus mit, der den herkömmlichen Block-I/O-Layer und damit die Scheduler und deren Schwächen insgesamt umgeht. Hierbei handelt es sich um den Multi-Queue Block-IO Queueing Mechanism (blk-mq), der für per PCIe angeschlossene Geräte bereits mit Kernel 3.13 realisiert wurde [15]. Dieser Mechanismus ist allerdings noch nicht standardmäßig freigeschaltet, ergab in einem zweimonatigen Dauertest jedoch keine negativen Auswirkungen.

Blk-mq lässt sich bereits jetzt freischalten, ohne dass Sie dazu den Kernel neu bauen müssten. Erstellen Sie dazu als Root zunächst die Datei /etc/modpobe.d/scsi-mod.conf und fügen Sie als Inhalt die Zeile options scsi-mod use_blk_mq=1 ein (die Kommandos aus Listing 10 erledigen das für Sie in einem Rutsch). Lesen Sie nun nach einem Neustart erneut den aktiven Scheduler aus, dann sollten Sie als Ergebnis lediglich none zurückbekommen.

$ sudo touch /etc/modpobe.d/scsi-mod.conf
$ echo options scsi-mod use_blk_mq=1 | sudo tee /etc/modpobe.d/scsi-mod.conf
[... Neustart des Rechners ...]
$ cat /sys/block/sda/queue/scheduler
none

Benchmarks

Die Verbesserung der Schreib/Leseleistung lässt sich in der Praxis besonders gut beim Löschen vieler kleiner Dateien beobachten. Für einen Test entpacken wir den Quellcode des Linux-Kernels mit einer Gesamtgröße von 497 MByte und 36?706 kleinen Dateien. Nach dem Entpacken syncten wir alle temporär gespeicherten Daten, löschten den entpackten Quellcode und schrieben erneut mit sync den Zwischenspeicher auf die Platte.

Die Zahlen aus der Tabelle “SSD-Leistung” sprechen eine deutliche Sprache: Mit Online Discard benötigt besonders das Löschen vieler Dateien sehr viel Zeit. Dies braucht gegenüber einem Batch Discard, das Sie nur ab und an von Hand oder per Skript ausführen, über 40 Sekunden mehr Zeit.

Fazit

SSD gehören heutzutage eigentlich in jeden Rechner. Sie arbeiten absolut geräuschlos, zuverlässig und stromsparend. Wer einmal das Vergnügen hatte, an einem Rechner mit einer SSD zu sitzen und selbst auf große Programme wie LibreOffice nicht länger als ein paar Wimpernschläge warten musste, der möchte eine SSD in Zukunft nicht mehr missen.

Waren vor ein paar Jahren noch etliche Klimmzüge nötig, um eine SSD unter Linux optimal einzurichten, so müssen Sie heute nicht mehr viel beachten. Aktuelle Linux-Distributionen wie Ubuntu 14.04 binden SSDs korrekt ein. Nur für das letzte Quäntchen Leistung müssen Sie noch von Hand eingreifen. Es lohnt sich also, auf eine SSD umzusteigen – ein Artikel aus LU 06/2014 hilft Ihnen bei der Migration [16].