Ein ungeplanter Dateisystem-Check ist nicht nur für den Heimbenutzer störend, er kann sogar geschäftsschädigend sein – wenn Downtime Geld kostet. Gleich vier Journaling-Filesysteme versprechen Besserung für geplagte Linux-Benutzer in beiden Bereichen.

Traditionell schreiben Unix-Dateisysteme Metadaten teilweise asynchron, was im regulären Betrieb für eine deutliche Beschleunigung sorgt, im Fall eines Systemabsturzes aber eine aufwändige Überprüfung des gesamten Dateisystems notwendig macht. Da die durchschnittliche Größe von Festplatten im Verhältnis zum Datendurchsatz in den letzten Jahren überproportional gestiegen ist, hat sich die Dauer eines Filesystemchecks stark verlängert, er kann mehrere Stunden beanspruchen. Das ist bereits bei einem unbeaufsichtigten Reboot sehr störend, vor allem wenn ein nicht automatisch zu behebender Fehler einen manuellen Eingriff erforderlich macht.

Journal-Typen

Aus diesem Dilemma führen zwei Wege: Entweder muss das Dateisystem die Strukturen auf der Festplatte trotz verspäteten Rückschreibens immer konsistent halten oder alle Veränderungen sofort sequenziell in einem fortlaufenden Journal oder Log protokollieren. Ersteres wird beispielsweise in den FFS-Implementationen aktueller 4.4BSD-Derivate (Soft-Updates)[1] oder vom UFS in Calderas OpenUNIX (Delayed Ordered Writes)[2] verwendet.

Unter den Dateisystemen, die ein Log führen, kann man zwischen zwei Typen unterscheiden. Journaling-Dateisysteme verwenden das sequenzielle Log nur temporär zum Protokollieren von Änderungen; sie schreiben die Daten später in die eigentliche Dateisystem-Organisation zurück. Log-structured-Dateisysteme hingegen verwenden das Log für die eigentliche Dateisystemorganisation; ein Zurückschreiben ist also nicht nötig. Nachteilig ist hier jedoch die starke Fragmentierung der Dateien: Bei jeder Dateimodifikation werden die Daten weiträumig auf der Platte verteilt.

Auch wenn sich dieser Artikel nur mit der ersten Variante beschäftigt, gibt es einige Log-Structured-Filesysteme für Linux. Das noch sehr experimentelle LinlogFS[3] ist für den Einsatz mit normalen Festplatten konzipiert, JFFS und JFFS 2 hingegen funktionieren nur auf Flash-Speichern in Embedded Devices, sind dafür aber Teil des Kernelbaums.

Binärbäume und Extents

Von einer Ausnahme (Ext3) abgesehen unterscheiden sich die Testkandidaten auch in anderen Aspekten als der zusätzlichen Log-Funktion von der Vorgängergeneration, der unter anderem UFS und Ext2 angehören. So benutzen beispielsweise XFS und JFS Binärbäume für die Verwaltung der Inode- und Block-Allokationstabellen, bei ReiserFS sind balancierte B-Trees sogar die fundamentale Datenstruktur zur Verwaltung des Dateisystems.

Im Gegensatz zu blockbasierten Dateisystemen wie Ext2/3 benutzen XFS und JFS Extents, um auf Datenblöcke zu zeigen. Extents sind Block-Länge-Paare, die eine effiziente Verwaltung einer großen Zahl aufeinander folgender Blöcke ermöglichen.

ReiserFS

Das heute wohl am weitesten verbreitete Journaling-Filesystem für Linux ist ReiserFS. Interessanterweise sind die Journaling-Funktionen dieses Dateisystems bei weitem die jüngsten. Erst 1999 wurden sie von Chris Mason, einem SuSE-Mitarbeiter, dem vorher ein Schattendasein führenden Dateisystem hinzugefügt. So war SuSE 6.4 im März 2000 die erste große Distribution, die – nach einem kurzen Intermezzo der Journal-losen Version im Vorgänger – mit diesem Dateisystem ausgestattet war.

Seit Kernel 2.4.1 ist ReiserFS Bestandteil des offiziellen Kernels und wird somit auch bei 2.4-basierten Distributionen mitgeliefert. Caldera und Red Hat unterstützen es aus Stabilitätsgründen allerdings nicht offiziell.

Wer sich für die turbulente Geschichte dieses Dateisystems interessiert, dem seien die README[4] und die ReiserFS-Homepage empfohlen. Dort gibt es auch einen Ausblick auf Reiser4, der nächsten Dateisystemgeneration aus dem Hause Reiser. Gesponsert wird dieses Projekt übrigens von der DARPA, die schon den heute weit verbreiteten Berkeley TCP/IP Stack finanzierte.

Technisch gesehen ist bei ReiserFS die konsequente Verwendung von ausbalancierten Binärbäumen das herausragende Feature. Andererseits ist dies aber auch eine Ursache vieler Probleme: Zum einen kann beim Einsatz von B-Trees schon ein einziger Fehler in der Datenstruktur für einen erheblichen Datenverlust sorgen, zum anderen ist der Virtual Filesystem Switch (VFS) im Linux-Kernel auf traditionell Inode-basierte Dateisysteme ausgerichtet.

So war bis zum Kernel 2.4.6 kein zuverlässiges NFS-Exportieren von ReiserFS-Dateisystemen möglich und bis heute kann der Quota-Code im Standardkernel nicht mit ReiserFS zusammenarbeiten. Entschädigt wird der ReiserFS-Benutzer dafür aber mit einer überragenden Geschwindigkeit beim Verwalten von sehr kleinen Dateien.

Ext3

Eigentlich ist Ext3 von Stephen Tweedie ein alter Bekannter unter neuem Namen: weite Teile dieses Dateisystems sind unverändert vom bewährten Linux-Standarddateisystem Ext2 übernommen. Die Gemeinsamkeiten der ungleichen Brüder gehen so weit, dass ein sauber abgeschlossenes Ext3-Dateisystem auch vom Ext2-Treiber gemountet werden kann. Die eigentliche Journaling-Funktion ist sogar weitgehend außerhalb des Ext3-Treibers implementiert: Das »jbd«-Modul sorgt dafür, dass in einer versteckten Datei oder auf einer separaten Partition Buch geführt wird.

Mit Data-Journaling

Die Verwandtschaft zu Ext2 spiegelt sich derzeit auch eindeutig in der Featureliste wieder: Es gibt weder Extents noch B-Trees-Verzeichnisse, Inodes werden grundsätzlich bei der Erzeugung des Dateisystems angelegt. Dafür unterstützt Ext3 als einziger Kandidat im Test aber auch das so genannte Data-Journaling, also das Mitprotokollieren der eigentlichen Daten.

Doch schon im Normalbetrieb bietet Ext3 eine bessere Datensicherheit als alle anderen Konkurrenten, der Ordered- Writeback-Modus sorgt dafür, dass alle Daten sich nach Abschluss einer Transaktion auf der Platte befinden. Eine Transaktion ist zum Beispiel dann beendet, wenn die Datei von der Applikation geschlossen wird. Eine Betriebsart, in der nur Metadaten protokolliert werden, bietet Ext3 zwar auch, aber deren Einsatz bringt gegenüber Ordered Writeback keine großen Vorteile.

Für zukünftige Versionen sind einige Änderungen geplant, mit denen Ext3 auch in anderen Bereichen mit der Konkurrenz gleichziehen könnte[20].

Seit 2.4.7-ac4 ist Ext3 Teil des Alan-Cox-Kernelbaums, seit 2.4.15-pre2 auch des offiziellen Kerneltrees von Linus Torvalds. Es wird von den aktuellen beziehungsweise nächsten Versionen aller großen Distributoren unterstützt. Für Linux-2.4-Benutzer, die die allerletzte Version wünschen, finden sich unter[5] passende Patches.

Wer immer noch auf den 2.2er Kernel setzt, findet unter[6] Ext3-Patches für die jeweils aktuelle Linux-2.2-Release. Diese Version hinkt derjenigen für Linux 2.4 jedoch deutlich hinterher, so fehlt beispielsweise die Unterstützung für ein Journal auf einer separaten Partition, auch ist der Code deutlich weniger getestet. Selbst nachdem das Patch eingespielt ist, muss man sich Mühe geben, um Ext3 in den Kernel zu konfigurieren: Die entsprechende Option versteckt sich unter »Ext2 development code«.

SGI XFS

Bereits seit 1994 unter SGIs Irix im Dienst, ist XFS das älteste der hier vorgestellten Dateisysteme. Die Linux-Version[7] wurde 2000 nach langfristiger Vorankündigung freigegeben.

Im Gegensatz zu den anderen Dateisystemen benutzt XFS die Linux-Schnittstellen nicht direkt. Der Quellcode gleicht dem für Irix weitest gehend und interagiert mit dem Linux-Kernel über eine umfangreiche Emulationsschicht (Abbildung 1). Darüber hinaus brachten frühere Versionen des Linux-Ports noch sehr umfangreiche Änderungen in anderen Teilen des Kerns mit sich, so dass Kritiker schon davon sprachen, SGI habe hier nicht XFS auf Linux, sondern Linux auf XFS portiert. In aktuellen Releases sind diese Eingriffe allerdings auf ein Minimum reduziert, dennoch benötigt es immer noch die meisten Änderungen aller Dateisysteme außerhalb des eigenen Verzeichnisses.

Natürlich stellen derartige Eingriffe auch besondere Anforderungen an das Management der Quelltexte, so hat SGI unter[8] einen CVS-Baum für einen vollständigen Kerneltree samt XFS aufgesetzt. Darüber hinaus findet man auf der Homepage auch vorgefertigte Installer-Images für Red Hat 7.x.

Abbildung 1: Zusammenarbeit von Linux VFS, LINVFS und den Low-Level-XFS-Operationen.

Prozessor-abhängige Pagesize

Der Aufwand, der für XFS betrieben wurde, schlägt sich natürlich in den Features nieder, auch wenn Linux in dieser Hinsicht Irix noch deutlich hinterherhinkt. So bietet XFS eine ausgereifte Unterstützung für POSIX-ACLs und Extended Attributes und außerdem – schon lange vor den anderen Linux-Dateisystemen – den »O_DIRECT«-Modus an, also den Zugriff auf Dateien unter Ausschluss der System-Caches.

Einen großen Nachteil hat XFS für alle Benutzer, die Linux auf mehreren Plattformen betreiben: Die Blockgröße entspricht hier immer der Pagesize des verwendeten Prozessors. Die beträgt beim i386 4 MByte, beim Alpha/AXP jedoch 8 MByte. Noch schwieriger wird es bei Intels neuer Kreation, dem Itanium – hier ist die Pagegröße einstellbar, die XFS-Blockgröße hängt somit von der spezifischen Kernelkonfiguration ab.

Abbildung 2: Hans Reiser, Ame- rikaner mit deutsch klingendem Namen, ist der Initiator von ReiserFS und der Entwicklungsfirma Namesys.

IBM JFS

Erst letztes Jahr ins Linux-Rennen gegangen ist IBMs Journaled File System Technology for Linux, kurz JFS[9]. Es ist damit nicht nur das neueste der hier vorgestellten Dateisysteme, sondern auch der jüngste Spross in IBMs zweiter JFS-Generation. Weitere Mitglieder dieser 1999 begründeten Familie sind JFS für OS/2 und JFS 2 für AIX 5 (j2).

Die Verwandtschaft sorgt auch dafür, dass JFS Partitionen lesen kann, die unter OS/2 mit dessen JFS formatiert wurden. Verwaltet werden diese jedoch meist vom OS/2-LVM, für den man sich (ebenfalls von IBM) erst einmal Unterstützung mittels EVMS[10] holen muss. Inzwischen bei Version 1.0.9 angelangt erfüllt JFS alle Grundanforderungen an ein modernes Dateisystem.

Viele der besonderen Features, die JFS für OS/2 bietet, fehlen jedoch noch. Bis ACLs, Extended Attributes sowie die Möglichkeit, ein System im laufenden Betrieb zu defragmentieren oder zu vergrößern, implementiert sind, dürfte es aber nicht mehr allzu lange dauern, schließlich steht eine komplette ältere Version von JFS für OS/2 als Referenz unter der GPL im Web[11] bereit.

Außer Konkurrenz

Neben den vier voll funktionalen Dateisystemen im Test gibt es auch Treiber für fremde Journaling-Filesysteme, teilweise mit stark reduzierter Funktionalität:

NTFS, das Standarddateisystem von Windows NT/2000/XP unterstützt Linux seit 1995. Der Treiber wird aktiv entwickelt und unterstützt lesende Zugriffe problemlos. Schreibender Zugriff ist zwar vorhanden, führt aber derzeit zu reproduzierbaren (und dokumentierten) Datenverlusten.

Das Veritas Filesystem VxFS wurde ursprünglich von Veritas zusammen mit den Unix System Laboratories (USL) entwickelt. Es kam erstmals in SVR4.2MP, dem späteren Unixware zum Einsatz. Heute ist es Standardbestandteil einiger Unix-Derivate (Unixware/OpenUNIX, Reliant Unix) oder steht optional zur Verfügung (Solaris, HP-UX, Dynix/PTX).

Veritas verspricht seit längerem eine Linux-Version, sah sich aber leider nicht in der Lage eine Version für diesen Test herauszugeben. Außerdem gibt es eine freie Reimplementation, die unter dem Namen FreeVxFS läuft. Seit Kernel 2.4.5 offizieller Linux-Bestandteil, bietet sie aktuell nur Lese-Zugriff.

Einen Linux-Treiber für NWFS, also das Dateisystem von Netware 3.x/4.x, gibt es als freie Software von Timpanogas Research[12]. Der Treiber bietet sowohl lesenden als auch schreibenden Zugriff, sogar die RAID-Funktionen von Netware sind implementiert. Seit sich der Hersteller auf Biotechnologie konzentriert hat, ist es jedoch still geworden um dieses Dateisystem, das für Linux 2.0, 2.2, 2.4 und Microsofts Windows NT/2000 zu haben ist[13].

Benchmarks

Ein äußerst wichtiger Aspekt beim Vergleich von Dateisystemen ist deren Geschwindigkeit. Aus der großen Anzahl der verfügbaren Benchmarks sollen für diesen Vergleich zwei zum Einsatz kommen, und zwar Bonnie++[14], eine Weiterentwicklung des weithin bekannten Bonnie, und Postmark[15] von Network Appliance, hier allerdings in einer leicht modifizierten Version von Arjan van de Ven[16].

Die Auswahl erfolgte primär nach zwei Gesichtspunkten: Einerseits sollte der Test leicht reproduzierbar sein und deshalb nicht wie beispielsweise der (kostenpflichtige) SPEC SFS[17] eine aufwändige Umgebung aus mehreren Testrechnern erfordern. Andererseits sollte ein realistischer Workload bewertet werden – daher bleibt zum Beispiel Mongo[18], der Hausbenchmark von ReiserFS, unberücksichtigt.

Alle Testdurchläufe erfolgten auf derselben Hardware (siehe Kasten “Testplattform”) und wurden stets nach dem gleichen Muster durchgeführt: Start des Computers, Erzeugen des Testdateisystems, Übersetzung der Benchmarks auf dem Testdateisystem, Benchmarkläufe. Die Ergebnisse sind in Tabelle 2 sowie in Kasten 1 zu sehen. ( hmi)

Tabelle 1: JFS-Features im Vergleich

Tabelle 2: Postmark-Ergebnisse

Kasten 1: Bonnie++-Ergebnisse

------Sequential Output------ --Sequential Input- --Random-
                      -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
 
                 Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
 ext2            300M  5214  99 16800  15  4731   6  4435  80 14950  11 139.0   0
 ext3            300M  4861  96 16403  28  6384  10  4574  84 13528  11 134.0   1
 jfs             300M  3958  75 16334  14  6111   7  4665  84 14922  11 134.9   0
 reiserfs        300M  4934  98 15962  28  4851   7  4299  79 13692  12 138.8   1
 xfs             300M  4926  98 14926  24  6747  10  4568  84 14887  12 134.6   1
 
 
                       -----Sequential---- -------Random-------
                       -Create-- -Delete-- --Create-- -Delete--
 
                 files  /sec %CP  /sec %CP  /sec %CP  /sec %CP
 ext2               16   919  99 +++++ +++   958  99  2573  99
 ext3               16   275  99 15347 100   283  99  1899  99
 jfs                16  2915  24   984   9  1255  25   166   2
 reiserfs           16  7144  95  9385  99  6671  92  8147  99
 xfs                16   467  99 19944  99   418  99  1897  98