© Maksim Shebeko, 123RF.com

Linux unterstützt eine stolze Anzahl von Dateisystemen. Für das Lagern von Daten auf lokalen Platten haben sich im Rechenzentrumsbetrieb aber nur einige bewährt. Das Linux-Magazin präsentiert in seiner Auslese aktuelle Jahrgänge der Ext-Familie, von XFS, JFS sowie Btr-FS.

Beim Speichern von Daten spielt das lokale Dateisystem eine entscheidende Rolle. In der proprietären Unix-Welt ist das Verwalten großer Datenmengen ein alter Hut. Mit der Portierung von SGIs XFS [1] oder IBMs JFS [2] stehen die dort eingesetzten Technologien auch für Linux zur Verfügung.

Unix-Ahnen und Nachwuchs

Ext 4 [3], der jüngste Spross aus der bekannten Familie der Extended Filesystems, macht einige unschöne Beschränkungen seiner Vorgänger vergessen und möchte zu XFS aufschließen. Allgemein anerkannt ist Btr-FS [4] als das Linux-Standard-Dateisystem der Zukunft. Es schließt einige schmerzliche Lücken und hat für einige Distributoren sogar schon Produktionsreife erreicht.

Dieser Artikel stellt XFS, Ext 2, 3 und 4 sowie Btr-FS im Vergleich vor. Der Fokus liegt auf jenen Funktionen und Features, die den Anforderungen des modernen IT-Alltags entsprechen.

Datenverwaltung beschäftigt sich im Grunde mit dem Ablegen und Wiederfinden von Objekten. Im einfachsten Fall reicht dafür eine Liste als Hilfsmittel. Dieser Ansatz skaliert aber nicht – ein datenbankartiger Ansatz ist um Größenordnungen besser und daher ein oft verwendetes Mittel. Recht bekannt ist der Einsatz von B-Bäumen, die Daten in einer baumartigen Struktur organisieren. Diese besteht aus Verzweigungen (Knoten) und Blättern, die im allgemeinen Fall beide Daten enthalten können. Die Suche nach einem bestimmten Datum muss in einem Bruchteil der Gesamtdaten stattfinden. Im Idealfall ist der Suchpfad von der Wurzel bis zum Blatt immer gleich.

Bei Veränderungen der Daten im Dateisystem verändert sich auch die Baumstruktur und damit die Suchpfad-Länge. Ein erneutes Ausbalancieren wirkt dem entgegen. Daher leitet sich auch der Name B-Baum ab: balancierter Baum. Es gibt verschiede Varianten von B-Bäumen. XFS, JFS und Btr-FS verwenden B+-Bäume. Hier sind die Daten nur in den Blättern gespeichert und nicht in den Knoten. Ext 3 und Ext 4 benutzen ebenfalls eine Baumstruktur, verzichten jedoch auf das Ausbalancieren (daher auch kein B-Baum). Da außerdem Hashes der Dateinamen als Schlüssel dienen, spricht man von H-Bäumen (hashed Trees).

Protokollführer

Beim tatsächlichen Schreiben auf den Datenträger treffen zwei Anforderungen aufeinander, die sich eigentlich gegenseitig ausschließen: Zum einen sollen die Daten sicher auf der Platte landen, und das ist schließlich erst der Fall, wenn der entsprechende physikalische Vorgang stattgefunden hat. Zum anderen soll das Schreiben auch performant sein, die Anwender möchten möglichst nicht warten. Daher landen die Schreibzugriffe nicht unmittelbar auf dem Datenträger, sondern in einem Puffer.

Damit drohen aber Inkonsistenzen des Dateisystems bei einem Rechnerabsturz. Um das zu vermeiden, nutzen moderne Dateisysteme eine Art Protokoll der Schreibzugriffe. Von den hier vorgestellten Kandidaten verwenden alle (außer Ext 2) dieses so genannte Journaling. Während XFS und JFS nur die Metadaten im Journal speichern, können Ext 3 und 4 sogar die Daten selbst dort ablegen. Voraussetzung für Letzteres ist die Mountoption »data=journal« . Ext 4 schützt sogar die Integrität des Schreibprotokolls durch eine Prüfsumme.

Die Verwendung des Journals hat allerdings einen Preis. Jeder Schreibzugriff eines Journaling-Dateisystems führt zu zusätzlichem I/O zur Aktualisierung des Journals. Abhilfe kann ein separater Pfad für das Protokoll auf geeigneter Hardware schaffen. Solid State Disks (SSD) sind geeignete Kandidaten dafür.

Etwas anders sieht es bei Btr-FS aus. Im Unterschied zu den anderen Mitbewerbern benutzt dieses Dateisystem das Copy-on-Write-Verfahren (COW). Es schreibt die veränderten Daten in neue Blöcke statt die bisher benutzten zu überschreiben. Unter bestimmten Umständen, beispielsweise bei der Verwendung des Systemaufrufs »fsync()« , kann es zu unnötigen COW-Schreibzugriffen kommen. Daher sammelt Btr-FS solche Schreibzugriffe in einer Art Journal.

Erweiterung und Allozierungstricks

Ob gepuffert oder COW – letztlich muss der Dateisystemtreiber Platz auf dem Datenträger allozieren. Ext 2 und 3 folgen hier dem Beispiel der früheren UFS-artigen Dateisysteme und verwalten jeden Block einzeln. Dieses Vorgehen stammt allerdings aus einer Zeit kleinerer Datenmengen und Festplatten.

Mit wachsender Dateigröße steigt der Verwaltungsaufwand für das Dateisystem. Selbst mit Konstrukten wie mehrfach indirekten Zeigern ist die theoretisch adressierbare Blockanzahl – und damit die Dateigröße – recht beschränkt. In vielen Fällen finden zudem mehrere Schreibzugriffe gleichzeitig statt und vermindern die Chance, dass die Blöcke einer Datei benachbart sind.

Ext 4 hat hier endlich mit XFS und JFS gleichgezogen: Alle drei verwenden so genannte Extents. Das sind zusammenhängende Speicherbereiche, die das Dateisystem zur Datenallozierung benutzt. Für die Verwaltung kommen auch hier Baumstrukturen zum Einsatz. Bei Ext 4 befinden sich im Inode Verweise auf allgemeine Extent-Strukturen.

Für kleine Dateien besteht diese Struktur aus einem Kopfteil und dem eigentlichen Extent, das bis zu 128 MByte adressieren kann. Für große Dateien baut Ext 4 eine Baumstruktur auf. An der Stelle des eigentlichen Extent befindet sich dann ein Index, der auf weitere Extents beziehungsweise deren Kopfteil verweist (siehe Abbildung 1).

Abbildung 1: Das Dateisystem Ext 4 verwendet im Inode Verweise auf Extent-Strukturen, die baumartig organisiert sind.

Ein weitere Möglichkeit, die Daten möglichst benachbart auf der Festplatte unterzubringen, ist die verzögerte Block-Allozierung. Bei der Aufforderung zum Schreiben merkt sich der Dateisystemtreiber, wie viel Platz er für die Daten benötigt, alloziert aber noch keine Blöcke.

Im Fall, dass weitere Daten dazukommen, kann das Dateisystem dann einen entsprechend größeren Bereich allozieren und so sicherstellen, dass der Schreib-/Lese-Kopf keine unnötigen Bewegungen zu machen braucht. Dieses Verfahren – normalerweise als Delayed Allocation oder Allocation on Flush bezeichnet – beherrschen XFS, Ext 4 und Btr-FS.

Mehr und größer

Konkrete Langzeitplanung hinsichtlich der Dateisystemgröße ist in den heutigen dynamischen Umgebungen kaum möglich. Der Betrieb verlangt, das Dateisystem mit den Daten mitwachsen zu lassen. Alle hier vorgestellten Systeme meistern diese Aufgabe. Der Admin kann sie ohne Datenverlust und sogar im laufenden Betrieb vergrößern. Für Ext 2 und 3 sowie für XFS und JFS ist das Vorgehen ähnlich. Während der Admin XFS und Ext 4 durch ein gezieltes Kommando zum Wachstum bewegt, geschieht dies bei JFS über das sofortige Remounten mit Resize-Option. Voraussetzung ist jedes Mal, dass das drunterliegende Volume entsprechend freien Platz bietet.

Aufgrund seiner integrierten Datenträgerverwaltung spielt Btr-FS eine kleine Sonderrolle. Es macht den zusätzlichen Platz durch das Hinzufügen einer weiteren Festplatte auf Volume-Management-Ebene verfügbar.

Deutlich seltener, aber häufig genug, ist der Admin dazu gezwungen, dem Dateisystem Platz abzuknapsen. Sowohl XFS als auch JFS bringen keine entsprechende Funktion von Haus aus mit. Dem Administrator bleibt nur der mühsame Weg, die Daten zu sichern, das Volume zu verkleinern, ein neues, kleineres Dateisystem anzulegen und die gesicherten Daten wieder einzuspielen.

Die Mitglieder der Ext-Familie lassen sich verkleinern, allerdings nicht online. Neben dem Aushängen kommt auch noch ein »fsck« -Lauf dazu, der je nach Dateisystemgröße die ganze Aktion signifikant verlängert.

Am anderen Ende der Skala steht Btr-FS. Es lässt sich scheinbar mühelos im eingehängten Zustand verkleinern. Abbildung 2 zeigt eine Sitzung, in der der Admin zunächst ein 8 GByte großes Btr-FS auf 2 GByte verkleinert. Danach fügt er einen weiteren Datenträger der Größe 8 GByte hinzu und verfügt damit über 10 GByte Platz auf Dateisystemebene.

Abbildung 2: Btr-FS schrumpft und wächst: Der Admin kann das Dateisystem um 6 GByte verkleinern und anschließend einen 8 GByte großen Datenträger hinzufügen.

Datensicherung und -wiederherstellung sind Standardaufgaben eines verantwortungsbewussten Administrators. Dabei stellt schon die erste eine Herausforderung dar. Das Backup erfordert einen konsistenten Zustand des Dateisystems, im Betrieb unterliegen die Daten aber ständigen Veränderungen. Auf Dateisystemebene heißt dies, dass Dateien geöffnet und Daten zwischen der Anwendung und dem physikalischem Medium unterwegs sind. Sicherung mit Standardmethoden ist in diesem Zustand kaum möglich.

Erlauben die Wartungsfenster ein Aushängen des Dateisystems, kann der Admin eine Offline-Sicherung vornehmen. Mit wachsender Datenmenge kommt aber auch hier die Zeit als kritischer Faktor hinzu. XFS als gestandenes Unix-Dateisystem erleichtert dem Admin das Leben: Das Tool »xfsdump« erlaubt das Sichern des Dateisystems im laufenden Betrieb.

Schnappschüsse

Ein Alternative ist das Anfertigen von Snapshots. Zu einem beliebigen Zeitpunkt konserviert der Admin den Ist-Zustand aller Daten des Volume. Leider beherrscht gegenwärtig nur Btr-FS dieses Feature. Erste Patches für Ext 4 existieren schon, sind aber noch lange nicht produktiv einsetzbar [5].

XFS an sich unterstützt dieses Vorgehen durch die Möglichkeit, den Dateisystemzustand über »xfs_freeze« einzufrieren. Der Admin kann dann getrost einen Snapshot auf Volume-Ebene erstellen und für die Sicherung benutzen. Aber auch für die anderen Kandidaten besteht noch Hoffnung. Seit einiger Zeit kennt der VFS-Layer des Linux-Kernels das Freeze-Feature, und Ext 3 und 4 sowie JFS können Gebrauch davon machen [6].

Ein Blick hinter die Kulissen offenbart so manche unerwartete Beschränkung des Dateisystems. Die so genannten Inodes sind hier ein wichtiges Element. Inode-Nummern sind pro Dateisystem eindeutig und stehen in Eins-zu-eins-Beziehung zu Dateinamen. Sind keine freien Inodes mehr vorhanden, kann das Dateisystem auch keine neue Datei anlegen.

Ext 2 und 3 verhalten sich hier recht unflexibel. Beim Anlegen des Dateisystems – und nur dann – bestimmt der Anwender die Anzahl der verfügbaren Inodes. Dazu reserviert der Dateisystemtreiber entsprechend viel Platz auf dem Datenträger, der dann für die eigentlichen Daten nicht verfügbar ist.

Ext 4 schleppt die Schwäche seiner Vorgänger teilweise mit und verwaltet die Inodes durch Bitmaps fester Größe pro Blockgruppe. Allerdings kennt es auch die so genannten flexiblen Blockgruppen, die zumindest eine weniger strikte Platzierung der Inode-Verwaltungsinformationen erlaubt. XFS, JFS und Btr-FS hingegen verwalten die Inodes dynamisch. Wiederum kommen die bewährten B+-Bäume zum Einsatz.

Dies und das

Die Wunschliste vieler Linux-Admins für Dateisysteme enthält auch die Punkte Kompression und Verschlüsselung. Letztere ist bei XFS, JFS sowie der Ext-Familie nicht zu finden, zurzeit zumindest. Die Entwickler von Btr-FS haben diesen Punkt auf ihrer Agenda.

Schon verwirklicht haben sie die Kompression (siehe Listing 1). Bei den anderen Mitbewerbern sucht der Admin diese Funktion vergebens. Zu Zeiten von Ext 2 gab es zwar schon Ansätze für die Implementierung (Stichwort »chattr« ), die es aber dann doch nicht in den Kernel geschafft haben.

01 $ mount -o compress /dev/sdb1 /data
02 $ df -lh /data
03 Dateisystem Size Used Avail Use% Eingehängt auf
04 /dev/sdb1 8,0G 56K 8,0G 1% /data
05 $ dd if=/dev/zero of=/data/bigfile bs=1M count=512
06 512+0 Datensätze ein
07 512+0 Datensätze aus
08 536870912 Bytes (537 MB) kopiert, 4,42356 s, 121 MB/s
09 $ df -lh /data
10 Dateisystem Size Used Avail Use% Eingehängt auf
11 /dev/sdb1 8,0G 18M 8,0G 1% /data
12 $ umount /data
13 $ mount /dev/sdb1 /data
14 $ grep /data /proc/mounts
15 /dev/sdb1 /data btrfs rw,relatime 0 0
16 $ df -lh /data
17 Dateisystem Size Used Avail Use% Eingehängt auf
18 /dev/sdb1 8,0G 18M 8,0G 1% /data
19 $ dd if=/dev/zero of=/data/bigfile2 bs=1M count=512
20 512+0 Datensätze ein
21 512+0 Datensätze aus
22 536870912 Bytes (537 MB) kopiert, 3,34057 s, 161 MB/s
23 $ df -lh /data
24 Dateisystem Size Used Avail Use% Eingehängt auf
25 /dev/sdb1 8,0G 531M 7,5G 7% /data

Die Komprimierung aktiviert der Btr-FS-Admin über die Mountoption »compress« (Zeile 1). Während »dd« nun 512 MByte in Richtung Dateisystem schiebt (Zeile 5), kommen nur 18 MByte auf der Platte an (Zeile 11). Ist die Komprimierung deaktiviert, liefert »df« das erwartete Ergebnis: 512 MByte rein (Zeile 19) und 512 MByte raus (Zeile 25).

Die Genauigkeit von Zeitstempeln ist bei Ext 2 und 3 mit einer Sekunde für viele Zwecke zu grob. Ext 4 und die restlichen Kandidaten meistern diese Herausforderung und sind Nanosekunden-genau. Es fehlt allerdings noch an den entsprechenden Userland-Tools, um diese höhere Präzision auch auszuwerten.

Weltenwanderer

Die Auswahl eines Dateisystems ist im Nachhinein nicht so einfach zu ändern. In den meisten Fällen funktioniert das nur über die Methode: Sichern, »mkfs« , Wiederherstellen. Dazu muss das Sicherungsprogramm – und natürlich ebenso die Wiederherstellung – die Besonderheiten von Quell- und Ziel-Dateisystem berücksichtigen. Features wie Access Control Lists (ACL) oder erweiterte Attribute etwa sucht man bei Ext 2 vergebens, während das restliche Bewerberfeld diese sehr wohl bietet.

Umwandlungen innerhalb der Ext-Familie sind hingegen unter bestimmten Umständen ohne Datenverlust möglich. Ext 3 unterscheidet sich von Ext 2 eigentlich nur durch das Journal sowie die verwendeten H-Bäume zur Verzeichnisverwaltung. Die Repräsentation auf dem Datenträger ist ansonsten identisch und erlaubt es, sehr einfach hin und her zu wechseln.

Dies gilt bedingt auch für Ext 4, und zwar für die Neuerungen, die das so genannte Ondisk-Format nicht verändern. Eine Ext-3-Partition kann durch den Ext-4-Treiber von den neuen Block-Allozierungsfunktionen profitieren, ohne die Datenstrukturen auf der Festplatte verändern zu müssen. Anders ist es, wenn der Admin Extents aktiviert. Ohne manuellen Aufwand gilt diese Änderung nur für neue Dateien und macht das Dateisystem für den Ext-3-Treiber unansprechbar.

Ausgesprochen interessant ist die Möglichkeit, Extended-Dateisysteme in Btr-FS umzuwandeln und umgekehrt. Das Werkzeug »btrfs-convert« verwendet die Bibliothek »libe2fs« und besitzt daher Insider-Kenntnisse über die Ext-Mitglieder. Die Funktionsweise dieser In-Place-Migration stellt Abbildung 3 dar: In den freien Bereichen des Ext-Dateisystems platziert »btrfs-convert« die Metadaten von Btr-FS. Die eigentlichen Datenbereiche bleiben unberührt.

Abbildung 3: Ein bestehendes Ext-Dateisystem (oben) lässt sich in Btr-FS umwandeln. Dabei platziert das Konvertierungstool die Btr-FS-Metadaten in den freien Bereichen (Mitte). Die bisherigen Ext-Metadaten bleiben vorerst in einem Snapshot konserviert, bis der Admin sie löscht (unten).

Die bisher verwendeten Ext-Metadaten fasst Btr-FS zu einem Snapshot zusammen. Dieser repräsentiert den letzten Zustand des Ext-Dateisystems und hält den Weg zurück offen. Ist der Admin mit Btr-FS zufrieden und löscht den Snapshot, verschwinden auch die alten Metadaten, ihr Platz steht wieder zur Verfügung.

Geschichtsstunde

Unter den hier vorgestellten Dateisystemen ist Ext 2 der Veteran. Es erschien 1993, acht Jahre später zog Ext 3 in die Vanilla-Version des Linux-Kernels ein. Die Wachablösung durch Ext 4 fand 2008 statt. Das zweitälteste Dateisystem ist XFS. SGI führte es 1994 für das hauseigenen Unix-Derivat Irix 5.3 ein. Eine erste Betaversion für Linux erschien bereits 2000. Seit 2001 ist es produktiv mit dem Linux-Kernel einsetzbar.

Ebenfalls 2001 fand IBMs JFS in der Version 1.0 den Weg zu Linux. Natürlich gibt es ein Pendant für AIX, das allerdings auf den Namen JFS2 hört. Den Vorgänger JFS1 lieferte IBM 1990 mit AIX 3.1 aus. Mehrere Jahre arbeiteten die Entwickler an der Verbesserung von JFS. Ein Variante befand sich 1999 im Lieferumfang von OS/2, der Quelltext dieser Implementierung lieferte die Basis für die Portierung nach Linux.

Btr-FS ist mit Abstand der jüngste Spross der vorgestellten Systeme. Die Grundidee – ausschließlich B-Bäume einzusetzen – stellte IBM auf der Konferenz Usenix 2007 vor. Schon zwei Jahre später schaffte Btr-FS den Sprung in den Vanilla-Kernel.

Fazit

Tabelle 1 stellt die Features der Dateisysteme in einer Übersicht dar, sie verwendet Binärpräfixe (1 TiB = 1024 GiB). Von den hier vorgestellten Kandidaten sind die Ext-Dateisysteme und XFS für den produktiven Einsatz geeignet. Um JFS ist es recht ruhig geworden, vor ein paar Jahren sah es schon so aus, also hätte IBM den Support eingestellt. Dies ist zwar nicht Fall, aber die marktbeherrschenden Enterprise-Distributionen haben ihre Unterstützung beendet.

XFS, der andere Unix-Veteran, hingegen scheint sich im Aufwind zu befinden. SGIs Klassiker ist nach wie vor gefragt, wenn es um die Verwaltung großer Datenmengen geht. Der Einsatz für »/boot« und »/« ist eher selten. Auch liefert es mancher Distributor nur gegen Aufpreis. Red Hat bietet das XFS wieder in seinem Produkt-Portfolio an, und das leidige Thema Metadaten-Performance ist adressiert [7].

Im Umfeld der Enterprise-Distributionen scheint sich Ext 4 als Standard durchgesetzt zu haben. Doch Btr-FS gilt zu Recht als das Linux-Dateisystem der Zukunft. Oracle und Suse bescheinigen ihm mit ihren jüngsten Enterprise-Distributionen sogar Produktionsstatus. (mhu)