Früher galt: Mehr RAM macht den Rechner schneller. Heute dominieren Solid State Drives das Rennen um den schnellsten Durchsatz im Gesamtsystem.

Eine gut eingestellte Solid State Drive (SSD) arbeitet im Optimum um fünf bis sieben Mal schneller als eine herkömmliche Festplatte. Die einzelnen Speicherchips einer SSD unterscheiden sich grundsätzlich nicht von denen in einem USB-Stick – und die sind nicht gerade für ihre Geschwindigkeit berühmt. Die Geschwindigkeit kommt durch massiv parallele Zugriffe zustande, indem der Controller viele NAND-Flash-Chips gleichzeitig anspricht.

Während herkömmliche Festplatten Daten bevorzugt zusammen an einer Stelle speichern, verfolgen SSD eine andere Strategie: Sie verstreuen bewusst die Daten über die Speicherzellen. Um eine niedrige Latenz beim Datenzugriff sicherzustellen, nutzen moderne SSDs bis zu zehn Speicherkontroller. Solche Modelle kosten momentan noch relativ viel Geld, derzeit um die zwei Euro pro GByte. Das prädestiniert sie also vor allem als Systemplatte. Dabei spielen sie ihre Stärken aus: hohe Schreib- und Lese-Raten bei kaum messbaren Zugriffszeiten. Hinzu kommt, dass SSD kaum Energiehunger verspüren und im Gegensatz zu traditionellen Festplatten lautlos arbeiten. Die kleineren Kapazitäten mit Größen von 60 bis 120 GByte reichen als Systemdisk aus; als Datengrab eignen sie sich hingegen nicht. Wieso sich das künftig vermutlich ändert, verrät der Kasten “Bauweise”.

Der Support für Solid State Drives durch Linux-Kernel und Dateisystemtreiber befindet sich derzeit in starkem Wandel. Viele Informationen im Netz veralten daher schnell. Handgriffe, die bei der ersten Generation von SSD nötig waren, fallen heute weg; ein Parameter, der bei aktuellen Kerneln Sinn ergibt, wirkt bei älteren Kernel eventuell kontraproduktiv.

SSDs fassen die Bits in Gruppen zu sogenannten Pages zusammen. Dahinter verbirgt sich die kleinste Einheit, mit denen die Hardware auf eine SSD schreibt oder von dieser liest. Die Größe einer Page beträgt heute fast immer 4 KByte. Pages organisiert der Datenträger wiederum in Blocks. Diese umfassen heute meist 128 Pages, also 512 KByte. Ein Block ist die kleinste Einheit, die Sie auf einem NAND-Flash-Device löschen können (Erase Block Size, EBS). Sobald Sie einen Block löschen, verschwinden also 128 Pages auf einmal vom Datenträger. Wer genauer wissen will, wie SSD intern arbeiten, der findet auf Anandtech einen ausgezeichneten Artikel [1] dazu.

Einstellungen

Wenn Sie eine SSD in Betrieb nehmen, lohnt es sich, vorab ins BIOS zu sehen: Stellen Sie dort sicher, dass Sie bei den SATA-Einstellungen den entsprechenden Port aktiviert haben und dieser Hotplug unterstützt. Als Modus wählen Sie AHCI. Falls es im BIOS eine Option write back caching gibt, aktivieren Sie diese ebenfalls.

Im nächsten Schritt widmen Sie sich der Festplatte: Das saubere Ausrichten der Partitionen gilt als Grundlage für eine optimale Performance ebenso wie für ein langes Leben der SSD. Orientieren Sie sich dabei an der EBS, und wählen Sie ein Vielfaches davon. Stimmt die Blockgröße nicht mit der EBS im Controller überein, erzeugen Sie eine Menge unnötiger Schreib-, Lese- und Lösch-Zyklen. Wer sich tiefer in die Materie des Ausrichtens von Partitionen einlesen will, dem sei der Grundlagenartikel [2] des Kernel-Programmierers Theodore Ts’o empfohlen.

Sofern möglich, verwenden Sie GUID Partition Table (GPT) zum Partitionieren. GPT gehört zum EFI-Standard, dem designierten Nachfolger für das BIOS in PCs (siehe Kasten “UEFI und GPT kurz erklärt”). Im Zusammenspiel mit einem aktuellem BIOS spricht nichts gegen den Einsatz mit Linux.

Partitionieren mit GPT

Das Werkzeug zum Erstellen eines GPT heißt Gdisk. Es findet sich in den Repositories der meisten großen Distributionen. Unter Debian/Ubuntu nutzen Sie den folgenden Befehl zum Installieren des Programms:

apt-get install gdisk

Außer der Manpage existiert derzeit kaum Dokumentation zu Gdisk, zumindest nicht auf Deutsch. Einen guten Überblick über die Parameter vermittelt ein passendes Online-Tutorial [3].

Starten Sie Gdisk unter Angabe der Gerätedatei (Listing 1, Zeile 1), im Beispiel /dev/sdb. Jetzt erstellen Sie eine neue Partitionstabelle (Zeilen 6 bis 8) und legen über [N] die Partition an (Zeile 11). Die Frage nach der Nummer bestätigen Sie mit [Eingabe]. In Zeile 13 tragen Sie den Startsektor ein; mit 2048 sind Sie hier auf der sicheren Seite.

Bei der neuesten Version, Gdisk 0.6.14, brauchen Sie den Startsektor nicht mehr anzugeben: Sie setzt den Startsektor automatisch auf 2048. Diese Gdisk-Version erlaubt es außerdem, über den Expertenmodus ([X]) den Startsektor manuell festzulegen. Anschließend bestätigen Sie über [Eingabe] den Typ der Partition (Zeile 16).

Das Ergebnis sehen Sie über [P], mit [W] schreiben Sie die Informationen auf die Platte und verlassen die kleine Applikation. Anschließend formatieren Sie die SSD mit dem Dateisystem Ext4 (Zeile 33). Falls gewünscht, legen Sie analog weitere Partitionen an.

$ sudo gdisk /dev/sdb
Partition table scan:
  MBR: not present
  GPT: not present
Creating new GPT entries.
Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y
Command (? for help): n
Partition number (1-128, default 1): [Eingabe]
First sector (34-125045424, default = 34) nor {+-}size{KMGTP}: 2048
Last sector (2048-1250405424, default = 125045424) or {+-}size{KMGTP}: +120G
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700): [Eingabe]
Changed type of partition to 'Linux/Windows data'
Command (? for help): p
Disk /dev/sdb: 1250405424 sectors, 120 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE
First usable sector is 512, last usable sector is 1250405390
Partitions will be aligned on 512-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       200973567   120.0 GiB   0700  Linux/Windows data
Command (? for help): w
Do you want to proceed, possibly destroying your data? (Y/N): y
OK; writing new GUID partition table (GPT)
$ sudo mkfs.ext4 /dev/sdb1

MBR im Einsatz

Obwohl GPT klare Vorteile aufweist, ermöglicht ein klassischer Master Boot Record (MBR) ebenfalls das korrekte Ausrichten von Partitionen. Dabei kommt das Werkzeug Fdisk zum Einsatz. Hier gilt es, die Werte für die Köpfe (“Heads”) und Sektoren (“Sectors”) so zu definieren, dass sie mit der EBS oder einem Vielfachen davon korrespondieren. Dazu rufen Sie das Programm analog zum Beispiel in Listing 2 auf.

Wichtig ist hier die Angabe der Parameter -H 32 und -S 32 in Zeile 1. Ohne diese Angabe stünde als Resultat in Zeile 17 statt je 32 Köpfen und Sektoren je Spur die Angabe

255 heads, 63 sectors/track, 14593 cylinders

Damit wäre die Partition für das blockweise Löschen einer SSD nicht korrekt ausgerichtet.

$ sudo fdisk -H 32 -S 32 /dev/sdb
Command (m for help): o
[...]
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4) p
Partition number (1-4): 1
First cylinder (1-15711, default 1): 2
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +120G
Command (m for help): w
The partition table has been altered!
$ sudo fdisk -lu /dev/sdb
Disk /dev/sdb: 120 GB, 120056361856 bytes
32 heads, 32 sectors/track, 152638 cylinders
Units = cylinders of 1024 * 512 = 524288 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Device     Boot     Start         End        Blocks  Id  System
/dev/sdb1               2       14593     117218241  83  Linux

Für USB-Sticks macht immer wieder die Empfehlung die Runde, als Dateisystem Ext2 zu verwenden, um das Schreiben des Journals zu vermeiden. Der gleiche Tipp findet sich vereinzelt für SSDs. Wollen Sie jedoch wirklich auf das Journaling verzichten, setzen Sie besser auf Ext4 und schalten per Tune2fs das Protokollieren aus. Auf das Altern der Platte hat das aber keinen Einfluss: Das Wear Leveling moderner SSDs sorgt ohnehin für das gleichmäßige Nutzen der Zellen.

Der Einsatz von Ext4 oder Btrfs empfiehlt sich aber noch aus einem anderen Grund: Derzeit unterstützen nur diese beiden Dateisysteme unter Linux den Trim-Befehl. SSDs erlauben kein Überschreiben von Daten. Um eine Zelle wieder zu nutzen, muss man sie vor dem Bestücken mit neuen Daten erst einmal löschen. Wie oben beschrieben geschieht das blockweise, entsprechend haben Sie die Partitionen angelegt. Nun kommen die Stichworte Trim und Wear Leveling ins Spiel: Wear Leveling bedeutet, dass der Controller alle Zellen so gleichmäßig wie möglich löscht und beschreibt. Der Trim-Befehl leitet das eigentliche Löschen ein.

Hinter Trim verbirgt sich eine Kommunikationsschnittstelle zwischen Dateisystem und Controller. Ein Betriebssystem mit Trim-Support fragt zuerst ab, mit welcher Geschwindigkeit die Festplatte rotiert. Gibt diese den Wert 0 zurück, handelt es sich um eine SSD, und je nach Betriebssystem schaltet dieses nun Funktionen wie Defrag (Windows 7) ab und Trim ein.

Löschen Sie nun eine Datei, sendet das System einen Trim-Befehl mit den von der Datei belegten Blockadressen gemäß LBA-Verfahren an den SSD-Controller. Der löscht die Daten dann zeitnah. Windows 7, Mac OS X ab 10.7 und Linux-Systeme mit einem Kernel ab Version 2.6.33 unterstützen den Trim-Befehl.

Einstellungssache

Haben Sie die Distribution Ihrer Wahl installiert, ist es an der Zeit, einige Einstellungen vorzunehmen, um die Geschwindigkeit und Langlebigkeit der SSD zu gewährleisten. Installieren Sie möglichst einen Kernel ab 2.6.38. Bei vielen aktuellen Distributionen findet sich dieser eventuell in speziellen Repositories.

Anschließend schauen Sie in die Datei /etc/fstab. Hier finden Sie für jede Partition, die Sie eingebunden haben, eine separate Zeile. Diese beginnt mit der UUID der Partition, danach folgen das Verzeichnis, unter dem Sie diese gemountet haben sowie der Dateisystemtyp. Anschließend finden Sie die Optionen, die das System beim Einbinden berücksichtigt, sowie zwei Ziffern, die für Checks und Backups relevant sind. Hier gilt es mit Vorsicht zu arbeiten (siehe Kasten “Was Sie nicht machen sollten”).

Ändern Sie, falls vorhanden, die Option relatime in noatime. Damit stellen Sie sicher, dass das System nicht bei jedem Lesevorgang den Zeitstempel einer Datei ändert. Nun schalten Sie noch das automatische Trimmen ein, indem Sie die Mount-Option discard einfügen. Mit Kernel-Versionen kleiner 2.6.38 ergibt die Option nicht viel Sinn, in manchen Fällen wirkt sie sich sogar kontraproduktiv aus.

Trim testen

Nachdem Sie den Befehl sudo mount -o remount / benutzt haben, um die Änderungen in /etc/fstab zu übernehmen, testen Sie, ob Trim funktioniert. Im Beispiel in Listing 3 liegt die Root-Partition auf einer SSD, die das System als /dev/sdb anspricht. In Ihrem Computer heißt die Gerätedatei eventuell anders.

Mittels Dd schreiben Sie zunächst einige Zeichen in 512-KByte-Blöcken auf die Platte. Der Hdparm-Befehl in Zeile 2 liest nun die Anzahl der belegten Sektoren aus. Über begin_LBA erfahren Sie, bei welchem Block die Daten beginnen. Diesen Wert verwenden Sie in Zeile 3 und Zeile 5 anstelle des Platzhalter Sektor. Wirft der erste dieser beiden Hdparm-Befehle Zeichen aus und der zweite aus Zeile 5 nur Nullen, dann funktioniert Trim.

$ dd if=/dev/urandom of=/tempfile count=100 bs=512k oflag=direct
$ sudo hdparm --fibmap /tempfile
$ sudo hdparm --read-sector Sektor /dev/sdb
$ rm /tempfile && sync
$ sudo hdparm --read-sector Sektor /dev/sdb

Falls bei einem älterem Kernel Probleme mit der Mount-Option discard auftreten, verwenden Sie das Skript wiper.sh aus dem Paket hdparm ab Version 9.25, dass Sie per Cronjob einmal pro Woche aufrufen. Alternativ bietet sich das Tool Disktrim [4] an. Stellen Sie aber sicher, dass die von Ihnen eingesetzte SSD den Trim-Befehl unterstützt. Einige ältere SSDs brauchen dazu ein Firmware-Update. Die aktuelle Firmware-Version verrät Ihnen der folgende Befehl:

$ sudo hdparm -iv Gerätedatei

Für SSDs von OCZ existiert unter Linux das Tool Fwupd [5], mit dem Sie die Firmware der SSD aktualisieren.

Sofern Ihr Rechner über genügend RAM verfügt (mehr als 4 GByte), lohnt es sich, das Verzeichnis /tmp in den Hauptspeicher verschieben. Das tun Sie in der Datei /etc/fstab mit den folgenden Zeilen:

tmp  /tmp      tmpfs  defaults,nodev,nosuid,mode=1777 0 0
shm  /dev/shm  tmpfs  defaults,noatime 0 0

Eventuell gilt es, alte Zeilen für das Tmp-Verzeichnis aus der Datei zu entfernen. Damit vermeiden Sie einiges an unnötigen Schreibzugriffen. Bei Bedarf limitieren Sie die Größe von /tmp durch einen Parameter wie size=1G in obiger Zeile.

Optimierungen

Der Standard-Scheduler des Kernels eignet sich nicht für SSDs. Wollen Sie das Beste aus der Hardware herausholen, testen Sie die anderen Scheduler, die das System mitbringt. Das Kommando aus Zeile 1 von Listing 4 zeigt die auf einem Debian-System vorhandenen Scheduler. Der Completely Fair Queueing Scheduler (CFQ) ist als Default eingestellt.

Die Scheduler noop und deadline eignen sich allerdings eher für den Einsatz von SSDs. Mit dem Befehl aus Zeile 3 wechseln Sie zur Laufzeit bis zum nächsten Reboot auf deadline als Scheduler. Ein letzter Test zeigt, dass das Umschalten funktioniert hat (Zeile 5).

$ sudo cat /sys/block/sdb/queue/scheduler<C>
noop deadline [cfq]
$ sudo echo deadline > /sys/block/sdb/queue/scheduler
$ sudo cat /sys/block/sdb/queue/scheduler
noop [deadline] cfq

Am Ende des Artikels finden Sie Benchmarks, mit denen Sie die Auswirkungen eines neuen Scheduler ganz einfach prüfen. Auf dem Testsystem brachte der Scheduler deadline zusätzliche 4 MByte/s Durchsatz, noop sogar 6 MByte/s. Auf parallel getesteten System erzeugten beide keine Veränderung. Haben Sie sich für einen Scheduler entschieden, tragen Sie in /etc/rc.local die folgende Zeile ein:

sudo echo Typ > /sys/block/sdb/queue/scheduler

Haben Sie im BIOS die Option write back caching aktiviert, installieren Sie jetzt das Programm Hdparm in einer Version neuer oder gleich 9.25. Dann setzen Sie zum Aktivieren von write back caching folgenden Befehl ab:

$ sudo hdparm -W1 /dev/sdb

Dieser Befehl verliert beim nächsten Reboot ebenfalls seine Wirkung. Sie aktivieren diese Option permanent durch einen Eintrag in /etc/hdparm.conf (Listing 5).

command_line {
       hdparm -q -W1 /dev/sdb
}

Um sowohl die Lebensdauer wie auch die I/O-Performance zu erhöhen (laut Ergebnissen von Intel auf das bis zu 2,5-fache), setzen Sie das sogenannte Over-Provisioning ein. Dazu zweigen Sie beim Partitionieren etwa 10 Prozent des Speicherplatzes in einem unpartitionierten Bereich ab. Das vergrößert die Spare-Area, die jede SSD von Hause aus mitbringt. Dahinter verbirgt sich Speicherplatz, den der Controller als Cache verwendet. Den beim Partitionieren zusätzlich von Ihnen freigelassenen Raum schlägt der Controller der Spare Area zu und nutzt diesen entsprechend.

Um im Idle-Mode Strom zu sparen, unterstützen moderne SSDs das Device Initiated Power Management (DIPM). Die seit Kernel 2.6.24 unterstützte Funktion schalten Sie per Sysfs ein (Listing 6).

# hdparm -I /dev/sdb | grep Device-initiated
  Device-initiated interface power management
# echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

Benchmarking

Testen Sie eine SSD nicht zu häufig. Machen Sie alle nötigen Benchmarks, um die optimalen Einstellungen zu ermitteln, und sichern Sie die Ergebnisse für spätere Vergleiche. Beeindrucken Sie jedoch nicht jeden Interessierten mit einer komplette Benchmark-Suite.

Den einfachsten und schnellsten Benchmark erledigen Sie mit Hdparm (Listing 7). Als aussagekräftiger erweisen sich die Daten aus einem Versuch mit Dd (Listing 8, Zeile 1). Jetzt löschen Sie den Buffer-Cache, um die genaue Lesegeschwindigkeit direkt von der Platte zu bekommen (Zeile 3). Anschließend verbleibt das letzte File im Buffer-Cache. Nun messen Sie die Geschwindigkeit erneut (Zeile 5).

$ sudo hdparm -Tt /dev/sdb
 Timing cached reads: 23188 MB in  2.00 seconds = 11605.90 MB/sec
 Timing buffered disk reads: 1188 MB in  3.00 seconds = 395.48 MB/sec

$ dd if=/dev/zero of=/tempfile bs=1M count=1024 conv=fdatasync,notrunc
1073741824 Bytes (1,1 GB) kopiert, 2,18232 s, 492 MB/s
$ echo 3 > /proc/sys/vm/drop_caches
$ dd if=/tempfile of=/dev/null bs=1M count=1024
1073741824 Bytes (1,1 GB) kopiert, 2,55234 s, 421 MB/s
$ sudo dd if=/tempfile of=/dev/null bs=1M count=1024
1073741824 Bytes (1,1 GB) kopiert, 0,122594 s, 8,8 GB/s

Einen grafischen Benchmark namens Palimpsest finden Sie im Paket gnome-disk-utility. Die in Abbildung 1 gezeigten Werte kamen auf einem Testsystem mit einer OCZ Vertex 3 mit 120 GByte Kapazität zustande. Als zwei etwas aufwändigere Benchmarks stehen Bonnie++ und Compilebench (Abbildung 2) bereit. Für einen Vergleich zu anderen aktuellen SSDs konsultieren Sie zum Beispiel die Website von Anandtech [6]. 

Abbildung 1: Der Benchmark Palimpsest liefert in einer grafischen Oberfläche Benchmark-Ergebnisse.

Abbildung 2: Der Compilebench liefert umfangreiche Leistungsdaten über die Performance des Systems.