Login
Newsletter
Werbung

Do, 4. Juli 2013, 15:00

Linux-Dateisysteme im Vergleich

Ein neuer Benchmark

ext3 und reiserfs haben ausgedient, die Zeit ist reif für Btrfs. Das ist das Ergebnis des neuen Dateisystem-Benchmarks, der hier vorgestellt wird.

Im Artikel Das Dateisystem ext4 wurde das damals gerade erst als stabil freigegebene Dateisystem den Dateisystemen ext3, xfs, jfs und reiser3 gegenübergestellt. Dabei erreichte es in mehreren Disziplinen die Spitzenposition und stellte sich insgesamt als klare Verbesserung gegenüber ext3 und zumindest ebenbürtig zu xfs heraus.

Inzwischen hat sich einiges im Linux-Kernel getan. Der ganze Kernel, ext4 und mit Einschränkungen auch ext3 wurden weiter optimiert. Btrfs und Nilfs2 (zuvor nilfs) betraten, neben anderen Dateisystemen, die eine untergeordnete Rolle spielen, neu die Bühne. Insbesondere die sich allmählich abzeichnende Einsatzreife von Btrfs sollte Anlass für eine neue Runde von Benchmarks sein. Ursprünglich sollte auch Reiser4 mit getestet werden, das beim letzten Test nicht dabei war. Dazu kam es jedoch nicht, da das Dateisystem nicht mit dem aktuellen Debian-Kernel 3.2 zusammenarbeiten will. Reiser4 scheint ohnehin dem Untergang geweiht und wird offenbar kaum noch gepflegt.

Stattdessen wurde das Dateisystem ZFS mit in den Test aufgenommen. Von den Funktionen her ist es das wohl leistungsfähigste freie Dateisystem und quasi das Vorbild von Btrfs. Seine Implementierung in Linux lässt jedoch zu wünschen übrig, was hauptsächlich an der zur GPLv2 und damit zum Linux-Kernel inkompatiblen Lizenz liegt. Dennoch existieren zwei Implementierungen von ZFS für Linux. ZFS on Linux ist ein regulärer Dateisystem-Treiber im Kernel und wurde im April 2013 für alltagstauglich erklärt. Er kann jedoch wegen der Lizenz nicht gemeinsam mit dem Kernel ausgeliefert werden und muss somit vom Benutzer separat installiert werden. Die andere ist ein Modul, das mittels dem FUSE-Treiber (Filesystem in User Space) als Benutzerprozess ausgeführt wird. Wegen Problemen beim Compilieren konnte »ZFS on Linux« dieses Mal nicht getestet werden. Dagegen wurde zfs.fuse mit getestet, obwohl zu erwarten ist, dass es deutlich langsamer ist als native Dateisysteme.

Zum Test wurde das gleiche AMD Phenom-System wie beim letzten Mal verwendet, das inzwischen aber von 4 auf 8 GB RAM hochgerüstet und mit einer mehr als doppelt so schnellen Festplatte ausgestattet wurde. Daher sind die Ergebnisse nur untereinander, aber nicht mit den früheren Werten vergleichbar.

Durchführung

Das Benchmarksystem war ein AMD Phenom (4 Kerne) mit 2,4 GHz und 8 GB RAM. Als Kernel kam Linux 3.2 von Debian in der 64-Bit-Version zum Einsatz. Für den Test wurde ein logisches Volume von 100 GB Größe auf einer brandneuen Festplatte WDC WD30EFRX-68AX9N0 angelegt. Diese Festplatte könnte einen SATA-Link mit 6 Gbit/s nutzen, ein solcher stand jedoch nicht zur Verfügung. Aber auch die genutzten 3 Gbit/s lassen noch Luft nach oben bei der Übertragungsrate und stellten daher keine Einschränkung dar. Die maximale Geschwindigkeit der Platte liegt nach Herstellerangaben bei 145 MB/s und erreichte mit hdparm -tT 143 MB/s. Die äußeren Bereiche sind dabei wie bei Festplatten üblich deutlich schneller als die inneren, so dass im Mittel eher mit 130 MB/s zu rechnen ist.

Die erhebliche Größe von 100 GB für die Testpartition kommt zum einen dadurch zustande, dass Dateien mit der doppelten Größe des Hauptspeichers benötigt werden, womit ca. 20 GB einschließlich des Dateisystem-Overheads das Minimum gewesen wären. Manche Dateisysteme wie nilfs2 besitzen jedoch einen erheblich größeren Overhead, zumindest kurzzeitig, und benötigen somit größere Partitionen. Es stellte sich heraus, dass selbst mit 100 GB die Benchmarks mit nilfs2 nicht ohne Probleme liefen.

Zum Testen wurde wiederum bonnie++ verwendet. Dabei wurden die Optionen anders als beim letzten Test sorgfältig ausgewählt, um ein möglichst aussagekräftiges Ergebnis zu erhalten. Folgende Optionen wurden eingesetzt:

  • -s 16384m:256k Größe der Dateien (doppelt so groß wie RAM) mit 256K Chunk Size. Letzteres stellt die Größe der Datenblöcke bei I/O-Aufrufen dar; der Standardwert wäre hier 8K.
  • -n 128:1999:0:1 128K (131072) Dateien für den Dateierzeugungstest mit einer zufälligen Größe von 0 bis 1999 Bytes in einem einzelnen Verzeichnis. Mit dem Bestehen auf einem einzelnen Verzeichnis soll der Umgang der Dateisysteme mit großen Verzeichnissen getestet werden.
  • -f Kein Test der zeichenorientierten Operationen, die keine Relevanz haben (spart viel Zeit).

Cache-Effekte wurden durch die gewählte Dateigröße vom Doppelten des Hauptspeichers ausgeschlossen. Auch wenn Bonnie++ die einzelnen Dateien auf 1 GB begrenzt, sollte der Effekt nicht anders sein als eine einzelne Datei von Maximalgröße. Als I/O-Scheduler wurde CFQ verwendet, der im Mittel die beste Leistung bieten sollte. Ein Vergleich mit anderen Schedulern wurde allerdings nicht gezogen.

Um auf Anregungen einzugehen, die in Reaktion auf den ersten Test kamen, wurde auch ein zusätzlicher Test mit dem Entpacken einer großen Tar-Datei und anschließendem Löschen des Verzeichnisbaums vorgenommen. Die Tar-Datei war 1,7 GB groß und nicht komprimiert, um nicht die CPU-Geschwindigkeit bei der Dekompression, sondern die Dateioperationen zu testen. Der Inhalt bestand aus vier Kopien des unmodifizierten und nicht compilierten Linux-Kernel-Baums von Version 2.6.37, die in vier Unterverzeichnissen data1 bis data4 angeordnet waren.

Außerdem wurde der entpackte Verzeichnisbaum anschließend mit cpio wieder in ein Archiv gepackt (wiederum ohne Kompression). Danach wurde der Verzeichnisbaum gelöscht. Die Zeit wurde auch für diese beiden Aktionen gemessen.

Neu ist auch die Einführung von Optionen für die Erzeugung und das Mounten von Dateisystemen. Diese Optionen müssen nicht das Letzte aus den Dateisystemen herausholen, können aber bei einigen zu beträchtlichen Verbesserungen führen und sind auch gebräuchlich. Beim Erzeugen der Dateisysteme wurden dieses Mal noch keine speziellen Optionen eingesetzt. Beim Mounten wurde nur bei XFS (-o logbufs=8) und nilfs2 (-o pp=0) eine Option eingesetzt. Bei ext3 sollte man, um Datenverlusten bei Stromausfällen vorzubeugen, die Option barrier=1 setzen, wie auch in der Manpage mount(8) beschrieben. Mittlerweile ist die Option standardmäßig eingeschaltet. Sie führt zu einem Geschwindigkeitsverlust, der aber im Schnitt wohl unter 10% liegt. Eine Option, die auf allen Dateisystemen sinnvoll ist, die sie anbieten, ist relatime oder gar noatime. Denn das Speichern der letzten Zugriffszeit einer Datei erzeugt viel I/O, und es gibt praktisch keine Anwendung, die diese Zeit benutzt. Standardmäßig setzt der Kernel die Option relatime, aber noatime ist in manchen Tests noch einige Prozent schneller. In unserem Benchmark wurde noatime nicht verwendet, hauptsächlich deshalb, weil es vergessen wurde.

Alle Tests wurden fünfmal durchgeführt, und die jeweils besten erzielten Ergebnisse gewertet. Daher benötigte der gesamte Test fast einen Tag Laufzeit, und der Aufwand zur Vorbereitung und Auswertung war entsprechend.

Die rohe Protokolldatei des Benchmarks mit jeweils drei Durchläufen steht hier zum Download zur Verfügung. Das Skript »diskbenchmark« kann man hier herunterladen. Verbesserungen sind willkommen.

Die nachfolgende Tabelle zeigt die Ergebnisse, wobei als redundant erachtete Werte, die bonnie++ lieferte, nicht betrachtet wurden. Der rot markierte Eintrag in jeder Zeile hebt den besten Wert hervor. In den Zeilen, in denen ext2 am besten abschnitt, ist zusätzlich noch der Bestwert unter den Journal-Dateisystemen markiert.

Bei nilfs2 trat eine Anomalie auf: Nach dem ersten Durchlauf von Bonnie++ hatte das Dateisystem keinen verfügbaren freien Platz mehr auf der 100 GB großen Partition. Aus diesem Grund wurde mit der Mount-Option -o pp=60 versucht, das Aufräumen zu beschleunigen und somit das Vollaufen zu verhindern. Doch weder -o pp=60 noch -o pp=1 oder -o pp=0 brachten ein perfektes Ergebnis, allenfalls leichte Verbesserungen. Immerhin konnten aber Messwerte gewonnen werden und es trat auch keine Instabilität auf.

Die Angaben zu Dateien erzeugen, stat und löschen beziehen sich auf die zufällige Reihenfolge; Bonnie misst auch die sequenzielle Methode. Die Zeiten sind die gemessene Gesamtzeit, außer beim Löschen, wo auch die reine Systemzeit ([sys s]) angegeben ist.

Benchmark-Ergebnisse
ext2 ext3 ext4 xfs btrfs jfs reiser3 nilfs2 zfs-fuse
Dateisystem 100 GB anlegen [s] 3,75 21,47 2,31 0,94 0,04 1,37 5,07 0,10 1,42
Dateisystem 100 GB mounten [s] 0,04 0,06 0,08 0,13 0,04 0,06 0,70 0,32 0,78
Datei 16 GB schreiben [MB/s] 122 89,5 122 131 134 135 109 95,4 61,8
Datei 16 GB lesen [MB/s] 128 119 132 128 109 132 117 119 105
Datei 16 GB löschen [sys s] 0,00 0,92 0,00 0,00 1,81 0,00 0,00 7,61 0,46
Datei 16 GB löschen [min Ges s] 0,00 0,96 0,00 0,00 1,82 0,04 0,00 7,62 3,92
Datei 16 GB löschen [max Ges s] 0,12 1,28 0,28 0,07 12,47 0,18 3,66 13,86 4,30
Seq. schreiben [MB/s] 109,6 83,7 118,0 120,5 122,4 117,5 85,8 75,0 62,3
Seq. lesen [MB/s] 133,9 140,0 133,5 132,4 121,5 147,8 136,4 80,9 112,8
Seeks [1/s] 122 112 122 115 115 134 125 82 89
Datei erzeugen [1/s] 695 14516 14193 6086 13421 910 3831 606 4646
Datei stat [1/s] 221571 81665 87667216153115771220937 547 235472 155
Datei löschen [1/s] 1612 11709 14404 13224 17810 191 466 1210 10203
Tar extrahieren [s] 56,46 94,37 41,56 60,24 46,32127,74100,56 82,57 194,12
Cpio erzeugen [s] 27,88 44,12 22,08 20,83 22,20 24,35 49,17 72,05 543,78
Verzeichnisbaum löschen [s] 5,09 16,37 7,84 23,40 8,63 83,09 7,98 3,17 170,71

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung