Flashspeicher reagieren empfindlich auf häufiges Schreiben. Linux bringt aber die richtigen Mittel mit, um die Lebenszeit des mobilen Datenträgers drastisch zu erhöhen.

Linux ist es völlig einerlei, ob Sie es auf eine Festplatte installieren oder auf einen USB-Stick: Der Kernel sieht in beiden Fällen ein Block-Device wie /dev/sda oder /dev/sdb. Das erleichtert die Installation eines portablen Systems (Abbildung 1). Sie finden in dieser Ausgabe einen Artikel, der sich ausführlich mit der Installation verschiedener Varianten beschäftigt.

Abbildung 1: Portable Systeme auf USB-Sticks, die auf jedem angeschlossenen Rechner booten, stellen für Linux kein Problem dar. Allerdings tun Sie gut daran, die Zahl der Schreibzugriffe zu dämpfen.

Doch der Linux-Kernel ist auf Festplatten mit beweglichen Leseköpfen hin getrimmt und nimmt von sich aus keine Rücksicht auf die Besonderheiten von Flashspeichern (vergleiche Kasten “Schreibvorgänge”). Das auf Server-Performance optimierte System schafft es so bei häufig genutzten Installationen, einen USB-Stick innerhalb einiger Monate zu ruinieren.

Wear and Tear

Die vom Linux-System geschriebene Datenmenge lesen Sie bei Bedarf aus der Proc- und Sysfs-Hierarchie aus. Die Zahl der seit dem Start auf ein Speichergerät angefallenen Blöcke finden Sie unter /proc/diskstats oder /sys/block/Gerätename/stat.

Der Aufruf aus der ersten Zeile von Listing 1 wandelt dabei die schwer zu entziffernde Reihe von Zahlen in einen MByte-Wert um, indem er Spalte 10 mit der Blockgröße von 512 Byte multipliziert und durch 1024 multipliziert mit 1024 teilt.

# awk '/sdNr/ {print $3"\t"$10 / 2048}' /proc/diskstats
# cat /sys/fs/ext4/sdNr/lifetime_write_kbytes
# tune2fs -l /dev/sdNr | grep created

Die ganze je in ein Dateisystem geschriebene Datenmenge zeigt das Kommando aus Listing 1, Zeile 2, dessen genaues Alter fördert der Befehl aus Zeile 3 zutage. So ergibt sich beim täglich genutzten Arch-Linux-System im Test pro Jahr eine Menge gut 500 GByte geschriebenen Daten für die Root-Partition und 1300 GByte für die Partition mit /home.

Die reine Menge der geschriebenen Daten erlaubt aber nur sehr bedingt Rückschluss auf die sich daraus ergebende Belastung für einen USB-Stick. Wie der Kasten “Schreibvorgänge” erläutert, bewegen die Controller selbst bei kleinen Zugriffen ein Vielfaches der eigentlichen Datenmenge in den Speicherzellen (“Write Amplification”).

Gegen diese Abnutzung kämpfen Flashspeichergeräte mit “wear leveling” an (Abbildung 2), bevorzugen also auf Controller-Ebene beim Schreiben bislang weniger belastete Speicherzellen.

Abbildung 2: Anders als bei konventionellen Festplatten ist der Flash-Controller in der Lage, die Daten ohne Einbußen bei der Performance beliebig zu verteilen.

Wie effizient die Controller dabei vorgehen, steht bei USB-Sticks allerdings in den Sternen – eventuell wechseln Steuerchip und Flashspeicher eines Sticks vom gleichen Typ je nach Preis auf dem Weltmarkt. Es existiert auch kein Verfahren wie SMART bei Festplatten, um den aktuellen Grad der Abnutzung auszulesen.

Als erster sehr grober Anhaltspunkt eignet sich die Annahme von 3000 Zyklen und einer Write Amplification von 10. Demnach wären Schreibzugriffe im 300-Fachen der Größe des Mediums möglich. Doch dabei hängt der Zeitpunkt des ersten Verlusts von Daten stark vom Muster des Zugriffs ab, und es existieren noch weniger Möglichkeiten, ihn vorherzusagen, als bei Festplatten.

Schweigen ist Gold

Da bei regelmäßig genutzten Linux-Installationen in weniger als einem Jahr Schreibzugriffe in der Größenordnung von ein bis mehreren Terabyte auflaufen, bietet es sich an, bei einer Installationen auf einem USB-Stick die Schreibwut des Systems zu zügeln.

Zum Glück kennt der Linux-Kernel seit Langem den eigentlich für das Energiesparen auf Notebooks konzipierten Laptop-Mode. Er bündelt das Sichern aus dem Cache im Arbeitsspeicher zu größeren Portionen. Das wirkt sich auch auf den Verschleiß von USB-Sticks oder SSDs positiv aus. Sie aktivieren den Laptop-Mode als root durch den folgenden Befehl:

# echo 5 > /proc/sys/vm/laptop_mode

Um ihn beim Systemstart auszuführen, schreiben Sie ihn unter Ubuntu in das Skript /etc/rc.local oder unter OpenSuse in /etc/init.d/boot.local. Die auf Notebooks oft genutzten Laptop-Mode-Tools [1], die zwischen Batterie- und Netzbetrieb differenzieren, erweisen sich für den Dauerbetrieb des Laptop-Modus als nicht sonderlich praktisch.

Um die Wirkung des Laptop-Modes zu erhöhen, schlägt die Kernel-Dokumentation vor, die Einstellungen dirty_expire_centisecs und dirty_writeback_centisecs auf zehn Minuten (3?600?000 Hundertstelsekunden) zu erhöhen (Listing 2, Zeile 1 und 2).

Um die Einstellungen dauerhaft zu nutzen, schreiben Sie die Befehle in die oben bereits genannten Startskripte. Das bewirkt, dass der Kernel die Daten zehn Minuten lang sammelt, ehe er sie auf die Platte schreibt – was ausreichend Arbeitsspeicher voraussetzt.

Hier zählt aber nicht der verfügbare Arbeitsspeicher, sondern der in dirty_background_ratio (Grenze für Synchronisation im Hintergrund) und dirty_ratio (Grenze, ab der die Synchronisation den Systemfluss unterbricht) festgelegte Prozentsatz. Setzen Sie daher beide Werte deutlich höher als die Standards von fünf und zehn Prozent, zum Beispiel auf 40 und 60 (Listing 2, Zeile 2 und 4).

# echo 3600000 > /proc/vm/dirty_expire_centisecs
# echo 3600000 > /proc/vm/dirty_writeback_centisecs
# echo 40 > /proc/vm/dirty_ratio;
# echo 60 > /proc/vm/dirty_background_ratio
# mke2fs -t ext4 -O ^has_journal Gerätedatei

Allerdings haben Entwickler die Möglichkeit, dieses Bündeln mit dem System Callfsync() zu unterlaufen. Der schreibt die Daten stets sofort auf die Platte. Da außerdem verzögertes Überschreiben existierender Dateien, wie es bei den Konfigurationsdateien von Gnome oder KDE laufend vorkommt, bei Abstürzen zu gefürchteten Null-Byte-Dateien führt [2], hat Ext4 für das Überschreiben von Dateien den alten Standard von Ext3 wieder eingeführt. Dabei sichert der Kernel zumindest die Wiederherstellungsdaten (“Journal”) jede Sekunde auf den Stick – und löst eventuell trotz geringer Datenmenge einen Löschzyklus aus.

Wer die Lebensdauer seines Flashspeichers höher gewichtet als die Gefahr des Verlusts von Daten beim versehentlichen Abziehen des Sticks, sollte daher das Journaling bei Ext4-Partitionen ganz abschalten (Listing 2, Zeile 5).

Vielschreiber

Zu den Hauptverursachern für viele Schreibzugriffe gehört das Verzeichnis /tmp. Daher legen viele Distributionen es zum Glück ohnehin aus Performance-Gründen als flüchtiges RAM-Filesystem an. Ob das der Fall ist, erkennen Sie daran, dass die Datei /etc/fstab eine Zeile wie in Listing 3 enthält.

tmpfs   /tmp   tmpfs   nosuid,size=15%   0   0

Fehlt der Tmpfs-Mount, sollten Sie ihn unbedingt hinzufügen, denn er verlängert die Lebensdauer des USB-Sticks deutlich. Da das System voraussichtlich nicht nur auf einem bestimmten Rechner läuft, ergibt es Sinn, für den Parameter size einen Prozentsatz des Arbeitsspeichers anstatt einer festen Größe anzugeben.

Weitere Verzeichnisse mit ebenfalls zahlreichen Schreibvorgängen wie /var/spool oder /var/tmp dürfen Sie jedoch nicht in ein flüchtiges RAM-Filesystem verlegen: Das System verlässt sich darauf, dass die Dateien in diesen Verzeichnissen einen Reboot überleben.

Bei den Programmen möchten die wenigsten auf die History-Funktion des Browsers, die mit dem ebenfalls häufig genutzten Ordner .mozilla zusammenhängt, verzichten. Hier springen die Tools Anything-Sync-Daemon [3] und Goanysync [4] in die Bresche: Sie kopieren beim Systemstart bestimmte Verzeichnisse in ein RAM-Filesystem, ersetzen sie durch einen Symlink und schreiben sie beim Herunterfahren zurück auf den Stick (Abbildung 3). Außer .mozilla sollte der Sync-Daemon auf jeden Fall noch .config, .cache, .kde4 und /var/log unter seine Fittiche nehmen.

Abbildung 3: Der Anything-Sync-Daemon arbeitet als Systemdienst, der kleine, oft genutzte Verzeichnisse beim Booten in ein RAM-Filesystem verfrachtet und beim Herunterfahren zurück auf den Stick schreibt.

Freilich rentiert sich dieser Kniff nur bei häufig beschriebenen Verzeichnissen, deren Größe im Rahmen bleibt, sonst vergrößert er die anfallende Datenmenge, statt sie zu verkleinern.

Ultima Ratio

Möchten Sie zum Äußersten gehen und die ganze Root- und Home-Partition in den Arbeitsspeicher spiegeln, braucht es einen tiefen Griff in die Trickkiste: Die speziell für USB-Sticks konzipierten Distributionen Slax [5] und Puppy Linux [6] setzen dazu auf das Overlay-Filesystem Aufs [7].

Dieses überlagert in Echtzeit ein Read-Only-Dateisystem vom USB-Stick, das die Masse der Dateien bereitstellt, und ein beschreibbares RAM-Filesystem, das nur die Änderungen seit Erzeugen des Read-Only-Parts enthält (Abbildung 4). Nur Letzteres schreibt das System beim Herunterfahren auf den Stick zurück – Programme und Anwender bekommen ein normal beschreibbares Dateisystem zu Gesicht.

Abbildung 4: Overlay-Dateisysteme wie Aufs überlagern Read-Only- und Read-Write-Anteile für Programme und Anwender transparent. Das System schreibt beim Shutdown den beschreibbaren Part zurück.

Ein schon etwas älterer Ubuntu-Community-Artikel [8] erläutert, wie Sie das Verfahren auf Ubuntu und andere Distributionen übertragen. Für Arch-Linux gibt es im Arch-User-Repository einen Kernel mit Aufs-Unterstützung [9]. Ubuntu hat Aufs inzwischen durch Overlayfs ersetzt – das allerdings immer noch von Grub 1 ausgeht.

Zu guter Letzt bleiben noch zwei Mythen auszuräumen: Die allenthalben empfohlene Mount-Option noatime, die das Schreiben des Zeitstempels beim Lesen von Dateien unterdrückt, verändert nur noch wenig, seitdem mit Kernel 2.6.38 das fast gleichwertige relatime zum Standard avanciert ist.

Auch das fehlende Ausrichten von Blöcken des Dateisystems mit den Löscheinheiten des Flashspeichers (Abbildung 5), die teilweise zwei Löschzyklen pro Schreibzugriff verursacht, brauchen Sie mit aktuellen Versionen von Fdisk und Parted/Gparted nicht mehr zu fürchten: Bei Fdisk schafft der Parameter -c Abhilfe, der die DOS-Kompatibilität abschaltet. Bei Gparted dürfen Sie lediglich die Einstellung MiB für das Ausklappmenü Ausrichten an (Abbildung 6) nicht antasten.

Abbildung 5: Nicht an den Löschblöcken des USB-Sticks ausgerichtete Dateisystemblöcke verursachen bei einem Schreibzugriff teilweise zwei Löschzyklen (magentafarben).

Abbildung 6: Beim grafischen Partitionierer Gparted richten Sie die Partitionen auf USB-Sticks für optimale Performance an der MByte-Grenze aus. Dann befinden sich die Einheiten beim Löschen und die Blöcke des Dateisystems sicher auf Linie.

Überall zu Hause

Um Linux auf die für kostengünstige Flashspeicher gebotene Datensparsamkeit zu trimmen, ist Handarbeit gefragt. Die Portabilität, welche die Installation des freien Systems auf USB-Sticks erst interessant macht, bringt es dagegen von Haus aus mit: Linux scannt die Hardware bei jedem Neustart und kommt dabei nicht nur mit einzelnen wechselnden Komponenten zurecht, sondern auch mit dem Anschließen des Root-Speichergeräts an einen neuen PC.

Die Einstellungen in /etc/modprobe.d, nach denen sich das System dabei richtet, sind fast immer generisch gehalten. Allenfalls bietet es sich an, Dateien in diesem Verzeichnis mit blacklist im Namen auf benötigte, aber unterdrückte Treiber zu untersuchen.

Wenn die Konfigurationsdatei /etc/fstab die Partitionen auf der Basis der UUID mountet, anstatt auf ein klassisches Device-File wie /dev/sda1 zurückzugreifen, stört es nicht einmal mehr, wenn sich die Zahl oder Reihenfolge der Speichergeräte verändert.

Der OpenSuse-Installer verwendet statt der UUID eine Device-ID, die auch Speichergeräte des gleichen Typs auseinanderhält, also ebenso zuverlässig funktioniert. Um solche Mountpunkte per Hand zu erzeugen, führen Sie ls -l /dev/disk/by-uuid/ aus. Sie sehen die UUIDs dann als Links auf das klassische Device-File.

Fenster auf

Als weitere Hürde bleibt noch der Start des X-Servers. Doch auch der steht heutzutage dem Kernel an Flexibilität um nichts nach: Findet er keine Konfigurationsdatei, so versucht er, mit den für das vorliegende System optimalen Einstellungen zu starten. Portable Systeme funktionieren daher am besten, wenn Sie die Datei /etc/X11/xorg.conf gar nicht erst anlegen und die modularen Konfigurationsdateien in /etc/X11/xorg.conf.d/ auf den von der Distribution eingerichteten Standardwerten belassen.

Dann sollte die grafische Oberfläche unabhängig von der Grafikkarte in maximaler Auflösung starten. Allerdings ist das Umsetzen des für die Abfrage der unterstützten Auflösungen zuständigen Protokolls EDID/DDC2 nicht in allen Bildschirmen korrekt umgesetzt.

Funktioniert der Umschalter für die Auflösung der Desktop-Umgebung nicht wie gewünscht, hilft Xrandr weiter. Ohne Optionen aufgerufen, listet das Tool alle Ausgänge der Grafikkarte und die erkannten möglichen Auflösungen und Wiederholfrequenzen der angeschlossenen Monitore auf (Listing 4). Um eine andere Auflösung aus dieser Liste einzustellen, genügt der folgende Aufruf:

$ xrandr --output DVI-I-0 --mode 1024x768 --rate 75

Damit stellen Sie 1024 mal 768 Bildpunkte mit der höchstmöglichen erkannten Bildrate von 75 Hz ein. Alternativ haben Sie die Möglichkeit, eine Auflösung einzustellen, die der X-Server wegen fehlerhafter Kommunikation mit dem Bildschirm nicht für möglich hält.

Screen 0: minimum 8 x 8, current 1280x1024, maximum 1280x1024
DVI-I-0 connected 1280x1024+1923+0 (normal left inverted right x axis y axis) 340mm x 270mm
   1280x1024      60.0*+   75.0
   1024x768       75.0     60.0
   800x600        75.0     60.3
   640x480        75.0     59.9

Zum Glück gelingt das dafür nötige Errechnen einer sogenannten Modeline (den Ansteuerungswerten des Monitors für eine bestimmte Auflösung) heutzutage dank des Tools Cvt ganz leicht (Listing 5).

$ cvt 1280 1024
# 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz
Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync
$ xrandr --newmode "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync
$ xrandr --addmode DVI-I-0 1280x1024_60.00

Rufen Sie Cvt mit der gewünschten Auflösung als Parameter auf (Listing 5, Zeile 1). Dann übergeben Sie die letzte Zeile abzüglich des ersten Worts Modeline an Xrandr (Listing 5, Zeile 4) und weisen die hinzugefügte Auflösung einem Bildschirm zu (Listing 5, Zeile 5). Dann haben Sie die Möglichkeit, mit dem Parameter --mode von Xrandr die Auflösung auszuwählen.

Fazit

Linux macht auf USB-Sticks eine ebenso gute Figur wie auf einer Festplatte. Bei sporadisch genutzten Installationen wie Rettungssystemen stört allerdings unter Umständen eine zu niedrige Auflösung.

Nutzen Sie ein portables System regelmäßig, dann lohnt es sich, dieses daraufhin zu optimieren, mit der begrenzten Zahl möglicher Schreibzugriffe auf preiswerten Flashspeichern sparsam umzugehen.