Login


 
Newsletter
Werbung
Mo, 19. Januar 2009, 00:00

Das Dateisystem ext4

Eigenschaften und Benchmarks

Zweieinhalb Jahre nach seiner ersten Ankündigung ist das neue Dateisystem ext4 bereit für den breiten Einsatz. Wir stellen seine Features vor und messen seine Leistung. Außer Konkurrenz machen wir auch eine erste Geschwindigkeitsmessung von btrfs.

Vorwort

Seit Mitte des Jahres 2006 ist jedem klar, dass das Dateisystem ext3 von Linux an Grenzen zu stoßen beginnt. Die maximale Kapazität von ext3 ist abhängig von der Blockgröße höchstens 8 Terabyte, was in LVM- oder RAID-Konfigurationen bereits seit einiger Zeit eine Einschränkung darstellen kann. Die derzeitige Auflösung von einer Sekunde bei Datei-Zeitstempeln wird schon seit längerer Zeit als unbefriedigend angesehen. Die Zeiten für das Prüfen bzw. Reparieren werden mit wachsender Größe eines Dateisystems immer weniger tolerierbar.

Statt die zur Lösung dieser Probleme kursierenden Patches in ext3 einzubauen und damit dessen Stabilität und Kompatibilität zu gefährden, begannen die Entwickler auf Initiative von Theodore Ts'o mit einem neuen Dateisystem ext4. Dieses sollte die Fähigkeit haben, ein bestehendes ext3-Dateisystem zu mounten und in ein ext4-Dateisystem umzuwandeln. Abgesehen von diesem Kompatibilitäts-Feature waren die Entwickler aber frei, beliebige Verbesserungen hinzuzufügen.

Mit ext4 kommt auch eine neue Version des Journaling Block Device (jdb2). Auch hier soll die neue Version dafür sorgen, dass die Originalversion stabil gehalten werden kann. Knapp drei Monate nach der ersten Ankündigung wurden ext4 und jdb2 in den Entwicklerkernel aufgenommen und in Linux 2.6.19 erstmals der Allgemeinheit zur Verfügung gestellt, allerdings ausdrücklich als experimentell markiert.

Eigenschaften von ext4

ext4 bringt in der initialen Version hauptsächlich Verbesserungen in Geschwindigkeit und Skalierbarkeit gegenüber ext3. Dazu gehören ein auf Extents beruhendes Format auf der Festplatte, 48-Bit-Blocknummern, Allokierung von mehreren Blöcken in einem Schritt, mehr als 32000 Unterverzeichnisse pro Verzeichnis, Reservierung von Verzeichnis-Inodes, Zeitstempel mit Nanosekunden-Auflösung, Inode-Versionen, Prüfsummen für das Journal und persistente Präallokation. Letztere ermöglicht es, Platz für eine Datei im Voraus zu reservieren. Dieser Platz bleibt reserviert und ist mit hoher Wahrscheinlichkeit zusammenhängend. Davon können Medienstreams und Datenbanken profitieren.

Die Dateisystem-Größe von ext4 ist maximal 1 Exabyte. Einzelne Dateien sind bei Blöcken von 4 KB (mehr ist aktuell nicht möglich) immer noch auf 16 TB beschränkt, was mit der Speicherung von Blocknummern als 32-Bit-Zahl zu tun hat. Diese Begrenzung soll noch fallen.

Sollte einmal ein Dateisystem-Check nötig werden, so müssen nur Blockgruppen geprüft werden, die auch allokiert sind. Das soll die Zeit für den Check stark reduzieren.

Aufgrund der Kompatibilität kann man ext3-Dateisysteme in ext4 umwandeln, ohne ein Backup mit Rücksicherung vornehmen zu müssen.

Anlegen und Betreiben von ext4

Ein ext4-Dateisystem wird analog zu einem ext3-Dateisystem auf einem nahezu beliebigen Blockgerät mit dem Kommando mkfs.ext4 [Devicename] oder mkfs -T ext4 [Devicename] angelegt.

Ein bestehendes ext3-Dateisystem kann man mit dem Kommando tune2fs -O extents [Devicename] in ein ext4-Dateisystem konvertieren. Von diesem Zeitpunkt an werden neue Dateien im Extent-Format angelegt, bestehende bleiben jedoch unverändert. Das neue Dateisystem kann nicht mehr als ext3 gemountet werden, eine Konvertierung zurück ist also ausgeschlossen. Ein ext3-Dateisystem kann jedoch als ext4 gemountet werden Es bleibt dennoch ein ext3-System, bis es explizit konvertiert wird.

Nach dem Anlegen kann das Dateisystem mit mount [Devicename] [Einhängepunkt] gemountet werden. Optional kann man den Typ des Dateisystems mit -t ext4 angeben. Das dürfte jedoch meist unnötig sein, da das Dateisystem automatisch erkannt wird.

Nach dem Mounten kann das Dateisystem wie jedes andere verwendet werden. Erweiterte Attribute und Security-Labels sollten wie bei ext3 zur Verfügung stehen. Ein kurzer Test zeigt, dass sich auf Systemen, die die Option, »große Dateien« zu verwenden, nicht besitzen, Dateien von maximal 2 TB Größe erzeugen lassen. Der andere Fall konnte leider nicht getestet werden.

Benchmarks

Durchführung

Testrechner war ein AMD Phenom (4 Kerne) mit 2,4 GHz und 4 GB RAM. Als Kernel kam Linux 2.6.28 in der 64-Bit-Version zum Einsatz. Für den Test wurde ein logisches Volume von 20 GB Größe auf einem RAID 1 angelegt.

Auf besondere Optionen beim Erstellen und Mounten der Dateisysteme wurde verzichtet. Zwar können diese durchaus Auswirkungen auf die Geschwindigkeit haben, aber bis zum Beweis des Gegenteils nehmen wir an, dass die von den Entwicklern vorgegebenen Parameter optimal sind. 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. In unserem Test haben wir diese Option allerdings nicht benutzt.

Ein erster Testlauf mit einem eigens erstellten Skript erbrachte unbefriedigende Ergebnisse. In diesem Lauf wurde jede Messung dreimal gemacht und das Benchmarkprogramm bonnie++ mit seinen Standard-Parametern verwendet. Die Ergebnisse zeigten große Schwankungen und erwiesen sich als unzureichend. Zudem wurde das System nicht optimal ausgereizt. Leider war es nicht möglich, die Schwankungen zu begrenzen, da das System während der Benchmarks wechselnden anderen Lasten ausgesetzt war. Ein Herunterfahren in Runlevel 1, wie es oft bei Benchmarks praktiziert wird, kam für uns nicht in Frage.

Um die Messergebnisse abzusichern, wurde daher ein weiterer Testlauf mit sinnvolleren Parametern für bonnie++ durchgeführt und jede Messung fünfmal wiederholt. Der ganze Test wurde später mit weiteren fünf Läufen wiederholt. Wo nicht anders angegeben, wurde jeweils das beste Resultat der insgesamt 10 Läufe gewertet. Cache-Effekte wurden durch eine Dateigröße vom Doppelten des Hauptspeichers ausgeschlossen.

Die beiden rohen Protokolldateien des Benchmarks mit jeweils fünf Durchläufen stehen hier und hier zum Download zur Verfügung. Das Skript »diskbenchmark« kann man hier herunterladen. Es ist offensichtlich noch verbesserungsfähig, so könnte man beispielsweise die Blockgrößen bei dd und bonnie++ konfigurierbar machen.

Pro-Linux
Forum
Neue Nachrichten
Werbung