Table of contents

Da mir Volker freundlicherweise seine brandneue Solid State Disk ausgeliehen hat um damit ein paar Tests durchzuführen, möchte ich meine Erfahrungen hier festhalten.

Solid State Disks sind „Festplatten”, die nicht magnetisch funktionieren, sondern stattdessen Flash-Speicher verwenden. Durch die starke Nachfrage nach Flash-Speicher in den letzten Jahren (beispielsweise durch USB-Sticks) wurden die Chips mit immer mehr Kapazität zu immer günstigeren Preisen verfügbar, was sie schließlich auch für Endkunden als Festplattenersatz in einigen Szenarien attraktiv macht (nichtsdestotrotz sprechen wir immernoch von ca. 180 € für eine 80 GB große SSD, Stand Dezember 2009).

Im Vergleich mit magnetischen Festplatten haben Solid State Disks einige Vorteile, beispielsweise sind sie deutlich robuster (keine beweglichen Teile, also insbesondere keinen Motor wie in einer herkömmlichen Festplatte), lautlos (aus dem selben Grund), verbrauchen weniger Strom und sind vor allem schneller. Der größte Geschwindigkeitsvorteil für den Alltagsbetrieb kommt daher, dass bei einer SSD auf Daten aus dem gesamten Speicherbereich zugegriffen werden kann, ohne dass erst ein Lesekopf positioniert werden muss. Das lässt die Zugriffszeiten bei Random Seeks von 10ms auf weniger als 0.1ms fallen, zu den Auswirkungen später mehr…

In diesem Artikel geht es darum, wie groß der Geschwindigkeitsvorteil in reellen Szenarien und in Benchmarks tatsächlich ist und insbesondere wie sich Vollverschlüsselung auswirkt. Als Betriebssystem kam Linux mit einem Standard-2.6.32-Kernel zum Einsatz, das Testgerät ist ein Thinkpad x200 mit einer Intel® Core™ 2 Duo P8400-CPU (2,26 GHz). Die getestete Solid State Disk ist die Super Talent Ultradrive GX MLC 256GB (2.5"), unter Linux als STT_FTM56GX25H (Firmware-Version 1819) erkannt.

Testbedingungen

Alle Tests wurden jeweils direkt nach dem Systemstart ausgeführt, sodass der Filesystem Cache keinen Einfluss hatte. Gemessen wurde auf einem zweiten Computer mit einer sekundengenauen Uhr (eine bessere Auflösung ist nicht nötig, da die Messungen in einigen Tests manuell durchgeführt wurden). Die einzelnen Tests wurden folgendermaßen ausgewählt und durchgeführt:

1. Bootzeit: Die Zeit, die das System zum Hochfahren braucht, also direkt nach dem Eingeben des Crypto-Passworts bis hin zum Anmeldebildschirm von xdm. Die Zeit davor ist irrelevant, da sie maßgeblich vom Kernel bestimmt wird (der wiederum wenige MB groß ist und dessen Ladezeit somit keine Rolle spielt). Die Zeit danach ist wiederum sehr von der Desktop-Umgebung des Nutzers abhängig. Bei mir startet i3 in weniger als einer Sekunde, unabhängig von der benutzten Festplatte. In diesem Test werden also die verschiedenen Initscripts ausgeführt und Systemdienste gestartet.
2. Debian-Paket i3: Hier wurde die Zeit gemessen, die der Befehl dpkg-buildpackage brauchte, um die Version 3.d von i3 zu kompilieren. Der Unterschied zwischen SSD und HDD ist hier hauptsächlich das Zusammensetzen des Debian-Pakets, welches beispielsweise die nötigen Dependencies automatisch herausfindet, indem es sich die entsprechenden Libraries auf dem System anschaut. Dieser Test soll repräsentativ für das Kompilieren von Software und das Bauen von Paketen für verschiedene Distributionen sein.
3. Firefox-Start: In diesem Test wird Firefox 3.5 gestartet (mit einigen Plugins, es geht hier nicht um die absolute Startzeit von Firefox, sondern um die Tendenzen bei einer SSD). Die Messung erfolgt ab dem Start bis hin zu dem Moment, ab dem die Session geladen wurde und der Browser auf Tastendrücke reagiert. Dieser Test ist stellvertretend für eine typische Desktopanwendung.
4. Paketinstallation: Zuletzt wird das Suchen, Installieren und Entfernen von Debian-Paketen gemessen. Als Paket für diesen Test habe ich Blender gewählt, welches mit 11 MB zu den eher größeren Paketen gehört. Alle nötigen Dependencies sind natürlich vorher bereits installiert, sodass der Test bei wiederholter Anwendung nicht verfälscht wird. Weiterhin wird das Paket nicht aus dem Netz geladen, sondern von der lokalen Festplatte. Dieser Test ähnelt dem typischen Systemupgrade oder dem Hinzufügen von neuen Paketen.

Die interne Festplatte, gegen welche die SSD antreten muss, ist eine FUJITSU MHZ2250BH G1.

Test 1: Fragmentierung bei ext4

Ich besitze mein Notebook nun etwas länger als ein Jahr und habe vor etwas weniger als einem Jahr das Dateisystem nach ext4 konvertiert. Über die Zeit hinweg wurde das System wöchentlich aktualisiert und beinhaltete unter anderem mehrere male den Linux-Sourcecode sowie einen kompletten Debian-Mirror. Es sind also zahlreiche Dateien vorhanden, was zu einer gewissen Fragmentierung führt. Den Grad der Fragmentierung habe ich nicht gemessen, da mir dazu keine Tools bekannt sind.

Im ersten Test möchte ich also wissen, wieviel schneller mein System wird, wenn ich alle Dateien kopiere, ein frisches ext4 anlege, und alle Dateien wiederherstelle. Da die SSD später ebenso befüllt wird, ist dies eine gute Vergleichsbasis.

Alltags-Szenarien mit fragmentiertem ext4 (LVM + dmcrypt)

1. Bootzeit: 40 Sekunden
2. Debian-Paket i3: 71 Sekunden
3. Firefox-Start: 14 Sekunden
4. Paketinstallation:
   • apt-cache search blender: 3 Sekunden
   • apt-get install blender: 83 Sekunden
   • apt-get purge -y blender: 8 Sekunden

Alltags-Szenarien mit frischem ext4 (LVM + dmcrypt)

1. Bootzeit: 32 Sekunden
2. Debian-Paket i3: 52 Sekunden
3. Firefox-Start: 13 Sekunden
4. Paketinstallation:
   • apt-cache search blender: 2 Sekunden
   • apt-get install blender: 49 Sekunden
   • apt-get purge -y blender: 8 Sekunden

Vergleich und Fazit

Es lohnt sich durchaus sein Dateisystem jedes halbe Jahr neu zu befüllen, solange es noch keine Programme gibt, um ext4 zu Defragmentieren (daran wird aber gearbeitet). Das ist dann eine ganz gute Gelegenheit, um zu testen, ob die Restore-Funktion deines Backup-Programms auch tatsächlich funktioniert :-).

Test 2: Partitionstabelle, LVM und Crypto auf der Solid State Disk

Bevor ich die SSD mit meinem System bespielt habe, habe ich grml von einem USB-Stick gestartet und damit ein paar Tests durchgeführt. Bei SSDs sollte man besonders darauf achten, dass die Blöcke, die geschrieben werden, 128 KB groß sind, denn ansonsten muss die SSD einen Lese-Schreib-Zyklus mehr ausführen (nicht nur der eigentliche Block muss geschrieben, sondern der benachbarte Block muss gelesen, verändert und erneut geschrieben werden).

Dazu gibt es verschiedene Stellen, an denen man ansetzen muss. Zum einen die Partitionstabelle, die angibt, wo die einzelnen Partitionen anfangen. Ein Zylinder sollte dabei ein Vielfaches von 128 KB sein (sofern die entsprechende SSD wirklich 128 KB große Blöcke hat). Theodore Ts'o schreibt, dass 224 Köpfe und 56 Sektoren derzeit die sinnvollste Variante sind, somit ergibt sich folgender Befehl:

# fdisk -H 224 -S 56 /dev/sda

Der Debian-Installer legt nun üblicherweise (sofern man sein System komplett verschlüsselt) eine kleine Partition für /boot an und eine verschlüsselte Partition für den Rest. Letztere enthält zunächst ein PV (Physical Volume) mit einer VG (Volume Group), die genauso heißt, wie das System. Darin befinden sich wiederum ein LV (Logical Volume) namens „root”, welches das eigentliche Dateisystem enthält, sowie ein LV namens „swap” für den Swapspace.

Wir haben also wiederum drei weitere Stellen, die angepasst werden müssen: Zunächst stellen wir sicher, dass dmcrypt die Nutzdaten (im Gegensatz zum Header) an einem 128 KB-Block abspeichert:

# cryptsetup -c aes-xts-plain -s 512 -y luksFormat /dev/sda2 --align-payload=256
# cryptsetup luksOpen /dev/sda2 sda2_crypt

Anschließend erstellen wir ein PV und geben an, dass die Metadaten insgesamt 256 KB umfassen sollen, sodass die Nutzdaten also wieder an einem 128 KB-Block anfangen (das LV für swap lege ich in diesem Beispiel nicht an):

# pvcreate --metadatasize 250k /dev/mapper/sda2_crypt
# vgcreate x200 /dev/mapper/sda2_crypt
# lvcreate -n root -L 230G x200

# Um die LVs zu finden und zu aktivieren:
# pvscan /dev/mapper/sda2_crypt
# vgchange -ay

Als letzten Schritt erstellen wir das Dateisystem, welches die Daten in 32 * 4 KB-Blöcke, also 128 KB-Blöcke verteilen soll.

# mkfs.ext4 -E stripe-width=32 /dev/mapper/x200-root

Weiterhin ist es erwähnenswert, dass man als I/O-Scheduler noop benutzen sollte, also kein Scheduling, da dies bei einer SSD nicht nötig ist (der Lesekopf muss nicht positioniert werden). Man startet also sein System mit folgendem Parameter in GRUB:

elevator=noop

Zum Testen habe ich nun Bonnie++ benutzt.

Vergleich und Fazit

Fazit: In der Praxis sind die Optimierungen auf Blockgröße nicht wirklich spürbar (die leichten Unterschiede lassen sich wohl am besten als Messungenauigkeiten erklären), einzig der Einbruch bei Nutzung von dmcrypt war erwartet und messbar. Trotzdem würde ich natürlich empfehlen, die jeweiligen Parameter zu setzen, schließlich ist es ja schnell gemacht und schlechter als garnicht ausgerichtet geht nicht…

Test 3: Solid State Disk und Vollverschlüsselung

Nachdem im vorigen Test die Datenrate stark einbrach und die Random Seeks etwas weniger, aber immer noch recht deutlich einbrachen, stellt sich die Frage: Wie sehr wirkt sich das auf die Alltagsszenarien aus?

Zum Test habe ich also einmal das System ohne Verschlüsselung auf die SSD kopiert und anschließend mit Verschlüsselung. Dann wurden dieselben Testfälle wie in Test 1 durchgeführt:

Solid State Disk ohne LVM und ohne Verschlüsselung

1. Bootzeit: 9 Sekunden
2. Debian-Paket i3: 27 Sekunden
3. Firefox-Start: 6 Sekunden
4. Paketinstallation:
   • apt-cache search blender: < 1 Sekunden
   • apt-get install blender: 11 Sekunden
   • apt-get purge -y blender: 5 Sekunden

Solid State Disk mit LVM und Verschlüsselung

1. Bootzeit: 9 Sekunden
2. Debian-Paket i3: 27 Sekunden
3. Firefox-Start: 6 Sekunden
4. Paketinstallation:
   • apt-cache search blender: 1 Sekunde
   • apt-get install blender: 13 Sekunden
   • apt-get purge -y blender: 6 Sekunden

Vergleich und Fazit

Glücklicherweise macht sich die Vollverschlüsselung in den Alltagsszenarien kaum bemerkbar. Lediglich die Paketinstallation ist überhaupt messbar langsamer (um insgesamt 3 Sekunden). Zum einfacheren Vergleich habe ich die Werte des frisch befüllten (ebenfalls verschlüsselten) ext4 auf meiner herkömmlichen Festplatte in die Grafik integriert.

Fazit

Die Solid State Disk von Super Talent ist ohne Zweifel sehr schnell (ich habe leider keinen direkten Vergleich zu anderen SSDs in meinem System) und kann einen deutlichen Leistungsschub verschaffen. Je nach Anwendungsfall ist die Vollverschlüsselung des Systems kaum merkbar, andererseits wird deutlich, dass nun wieder die Rechenleistung den Flaschenhals des Systems darstellt. Die 2010 erscheinenden Intel-CPUs der Westmere-Generation werden die zur Durchführung von AES nötigen Befehle direkt im Instruktionsset beinhalten (AES-NI) und dadurch hoffentlich deutlich mehr leisten. Da man auf einem System mit einer SSD aber vermutlich ohnehin eher arbeitet als viele Daten abzulegen (dafür sind magnet-basierte Datenträger derzeit doch deutlich günstiger), dürfte dieses Manko nur bei wenigen Anwendungsfällen ins Gewicht fallen.

Positiv aufgefallen ist mir, dass die SSD wirklich lautlos ist (oder die Geräusche komplett von den sonstigen Geräuschen wie CPU-Lüfter übertönt werden). Das macht das Arbeiten sehr angenehm, auch bei zugriffsintensiven Anwendungen (Suchen einer Datei beispielsweise).

Der geringere Stromverbrauch zeigt sich nicht sehr deutlich, lediglich ein halbes Watt weniger frisst die SSD (bei der herkömmlichen Festplatte war SATA power link management auf min_power eingestellt, sodass die Festplatte die meiste Zeit im idle-Modus verbringen dürfte). Je nach Akku und Gerät kann das ca. eine halbe Stunde mehr Laufzeit bringen.

Mir persönlich sind es die Vorteile noch nicht wert, mir eine SSD für mein Notebook zuzulegen. Oftmals möchte ich größere Dateien kopieren, wenn ich unterwegs bin und häufig macht sich der komplette Debian-Mirror bezahlt. Mit weniger als 200 GB möchte ich also im Notebook nicht ausgestattet sein, und für eine entsprechende SSD ist mir der derzeitige Preis von mehr als 500 € zu teuer. In meiner Workstation würde allerdings eine SSD als Systemplatte, ergänzt durch eine herkömmliche Festplatte für die Daten, durchaus Sinn ergeben :-).

PS

Übrigens: Die STT_FTM56GX25H (Firmware-Version 1819) hatte bei mir das Problem, dass sie, sobald SATA power link management auf min_power gestellt wurde, des öfteren hing (System steht, Festplatten-LED dauerhaft an, dann gibt es eine SATA Exception mit anschließendem Reset des Ports und es geht weiter). Als Lösung sollte man daher sicherstellen, dass die Einstellung nicht von ihrem Standardwert geändert wird. Beliebte Orte zum Ändern dieser Einstellung sind beispielsweise /etc/rc.local oder /etc/sysfs.conf.

Weitere Links

• Theodore Ts'o: Aligning filesystems to an SSD’s erase block size (insbesondere wegen der Erklärung des Wear-Leveling-Problems interessant, auf das ich in diesem Artikel nicht eingegangen bin.)
• Wikipedia: Solid State Disk
• Intel AES-NI
• Heise Preisvergleich: Super Talent Ultradrive GX MLC 256GB
• ssd.txt: die rohen Testergebnisse von Bonnie++