Seit dem 1. Mai steht auf der SGI-Website das journaled Filesystem XFS in der Version 1.0 zum Download zur Verfügung — unter anderem auch als Patch gegen den Kernel 2.4.2. Es liegt also nahe, es einmal in den Kernel von SuSE Linux 7.1 einzubauen.

Lange genug waren es Unix-Anwender gewohnt, ihre Systeme nicht einfach ausschalten zu können. Seit einigen Jahren gibt es allerdings absturzsichere Dateisysteme, die ähnlich wie eine Datenbank mit einem Log arbeiten, um Änderungen ständig mitzuschreiben. Mit SuSE 6.2 hielt das Reiser-Filesystem Einzug in die Linux-Welt, nachdem bereits seit Ende 1999 Stephen Tweedies Ext3-Dateisystem in höchst experimenteller und durchaus unstabiler Form vorlag.

SGI hatte bereits vor Monaten angekündigt, sein aus der Irix-Umgebung bekanntes XFS auf Linux zu portieren. Seit wenigen Wochen kann es nun jedermann im Sourcecode haben. Interessant wird XFS durch eine Reihe von Eigenschaften, die so bisher nicht oder nicht in der Zusammenstellung vorlagen:

• volle 64-Bit-Unterstützung
• Quotas
• extended Attributes, ACLs
• Dateigröße maximal 16 TByte mit 4-KByte-Seiten und 64 TByte mit 16-KByte-Seiten. Ist der Block-Device-Layer auf 64 Bit umgestellt, sind 9 Exabyte (9 ¥ 1018 Byte) große Dateien adressierbar.
• xfsdump und xfsrestore für die Dateisystemsicherung. Praktischerweise lassen sich Dumps, die unter Irix erstellt wurden, unter Linux einspielen und umgekehrt — trotz verschiedener Endianness.
• Ein Data Management API (DMAPI/XDSM) erlaubt die Implementation von hierarchischen Speichermanagement-Systemen ohne weitere Kernel-Änderung.
• Mit Hilfe von xfs_growfs können Dateisysteme im gemounteten Zustand wachsen (sie müssen dazu sogar gemountet sein). Die Anzahl der Inodes lässt sich im laufenden Betrieb ändern.
• Das Log kann auch auf einer separaten Partition oder einem anderen Logical Volume liegen. Für den Durchsatz ist das dann vorteilhaft, wenn das Log auf einer anderen physischen Platte liegt.

Patch den Kernel

Um XFS auf seinen Rechner zu bringen, muss der Nutzer zunächst die beiden Patches linux-2.4-xfs-1.0 .patch.gz und linux-2.4.2-core-xfs-1.0 .patch.gz wie gewohnt in den Kernel einbauen. Die SGI-Website [1] empfiehlt dazu, einen Standardkernel von ftp.kernel.org zu benutzen. Für Red Hat stehen RPMs und ein Installer zur Verfügung.

Spannend ist aber gerade der Vergleich mit Reiser FS, dem bislang einzigen logbasierten unter den verbreiteten Dateisystemen — und dazu bietet es sich an, das mit dem SuSE-Kernel 2.4.2 zu testen. Hinderlich kann sein, dass darin bereits eine ganze Reihe verschiedenster Patches enthalten ist, die weitere Veränderungen unmöglich machen oder zumindest erschweren.

Aber weit gefehlt — bis auf einen Reject bei einem Makefile läuft das Core-Patch anstandslos durch. Den Reject kann man getrost ignorieren; das zugehörige Patch ist in 2.4.2-SuSE bereits enthalten.

In der Kernel-Konfiguration sind die Optionen für den Page Buffer und das XFS zu aktivieren sowie eventuell DMAPI. Alle anderen XFS-Optionen dienen in erster Linie der Fehlersuche und sind hier nicht nötig. Es zeigte sich aber, dass das Core-Patch doch einen Stolperstein einbaut: Im obersten Makefile fand sich plötzlich die Zeile:

CC = $(CROSS_COMPILE)gcc 
     -V egcs-2.91.66

Dieser Aufruf geht schief, wenn man nicht zufällig die genannte Egcs-Version installiert hat. SuSE 7.1 kommt normalerweise mit Release 2.95.2, also gehört diese Zeile am besten auskommentiert. Hier zeigt sich die Anlehnung an Red Hat noch am deutlichsten.

page_buf cache Copyright (c) 2000 Silicon Graphics, Inc.
XFS filesystem Copyright (c) 2000 Silicon Graphics, Inc.
Start mounting filesystem: lvm(58,14)
Starting XFS recovery on filesystem: lvm(58,14) (dev: 58/14)
Ending XFS recovery on filesystem: lvm(58,14) (dev: 58/14)

seneca:/mnt #  df /dev/vg01/xfstest 
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/vg01/xfstest       650560     13752    636808   3% /mnt
seneca:/mnt # du -s -k .
13368   .

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/vg00/testlv         65528     32840     32688  51% /mnt
/dev/vg01/xfstest        60736        80     60656   1% /mnt

Riesiges XFS-Modul

Anschließend ist der Kernel ganz normal mit

make dep bzimage modules modules_install

zu übersetzen. make modules_install legt ein neues Verzeichnis /lib/modules/2.4.2-XFS für die Module an. Dort befinden sich dann auch die drei neuen Module pagebuf.o, xfs_support.o und xfs.o.

Nach Aktualisierung der /etc/lilo .conf sowie dem Aufruf von lilo und einem Reboot lassen sich die Module laden:

xfs        403600   0  (unused)
xfs_support   8400   0  [xfs]
pagebuf      23040   0  [xfs]

Das XFS-Modul selbst ist ziemlich umfangreich, wie man an der Anzahl der belegten Seiten sieht.

Um tatsächlich ein Dateisystem anlegen und benutzen zu können, ist es notwendig, die Tools in dem Paket xfsprogs zu übersetzen und in /usr/local zu installieren. Für den configure-Lauf muss e2fsprogs-devel installiert sein. Außerdem muss man in include/liblvm.h noch zwei Zeilen auskommentieren:

/*
#include "lvm_log.h"
#include "lvm_config.h"
*/

Wer mag, kann sich auch ein RPM-Paket aus den xfsprogs bauen [2].

Manpage-Salat

Bei Aufruf der Manpage zu XFS ist eine etwas lästige Namensgleichheit festzustellen: Es erscheint nämlich die zum X-Fontserver. Die für XFS heißt korrekt man 5 xfs.

Was das Dateisystem leistet, lässt sich am einfachsten mit dem bewährten Festplatten-Benchmark Bonnie feststellen. Dieser Benchmark testet die I/O-Zugriffsgeschwindigkeit mit einer großen Datei. Er schreibt zunächst zeichenorientiert, dann dasselbe noch einmal (rewrite) und schließlich blockorientiert. Gelesen wird zunächst zeichenweise, dann blockweise und zum Abschluss macht der Benchmark zufällige Suchvorgänge. Bonnie dürften die meisten Distributionen mitliefern, so dass ihn jeder benutzen kann.

Die Ergebnisse (siehe Kasten “Bonnie-Ergebnisse”) entstanden mit folgender Testumgebung: AMD K6-II/350 auf Tyan S1590S-Board, VIA Apollo Chipsatz mit VT82C586B IDE-Controller. Der SCSI-Controller war ein Symbios Logic 53C875 mit SYM53C8XX-Treiber. Festplatten: IBM DJNA-352030 (EIDE, UDMA-33), IBM DNES-309170W (Fast-20 Wide SCSI). Bonnie lief jeweils mit einer Testdatei von 512 MByte Größe, also etwa dem Doppelten des Hauptspeichers, um mögliche Cache-Effekte auszuschließen. Die drei ersten Zeilen beziehen sich auf die EIDE-Platte, die letzten drei auf die SCSI-Disk.

-------Sequential Output-------- ---Sequential Input-- --Random--
             -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU

XFS-IDE   512  2933 99.5 16210 28.7  5463 15.1  2755 89.1 15384 19.7 222.7  3.7
Reiser-I  512  2832 99.4 18695 65.1  5279 16.0  2783 88.9 16348 23.4 218.0  4.1
EXT2-IDE  512  2919 98.6 14652 26.7  4045 12.7  2643 83.3 10546 11.5 159.9  2.3

XFS-SCSI  512  2932 99.5 15241 28.7  5529 14.2  2795 90.8 15380 20.0 215.8  3.6
Reiser-S  512  2838 99.5 18533 61.2  5360 15.1  2733 87.6 15412 21.8 209.4  3.5
EXT2-SCS  512  2967 99.4 22915 38.8  5251 12.6  2670 84.2 15018 16.5 213.0  2.6

Beim Löschen eines ganzen Dateibaums ist XFS gegenüber Ext2 und Reiser FS merklich langsamer, allein große Dateien wird es im Vergleich viel schneller los.

Offenbar hat Reiser FS vor allem beim Schreiben großer Blöcke einen Geschwindigkeitsvorteil, allerdings erheblich auf Kosten der CPU-Last. Wenn eine reale Anwendung CPU-lastig ist und große Blöcke schreiben möchte, kann es durchaus sein, dass ein System mit XFS einen höheren Durchsatz bietet. XFS scheint auf der anderen Seite einen leichten Vorteil bei den Random Seeks zu haben, was vor allem beim Betrieb als OLTP-Datenbank günstig ist. Alle anderen Messwerte unterscheiden sich kaum — die Abweichungen liegen im Rahmen der Messtoleranz.

Schlaftablette auf IDE: Ext2

Wichtig auch der Vergleich mit dem altehrwürdigen Ext2 auf denselben Testpartitionen: Während es auf der IDE-Platte doch deutlich hinterherhinkt, spielt Ext2 auf der SCSI-Platte den einen oder anderen Trumpf aus und ist beim Blocklesen erheblich schneller, nicht aber beim Schreiben, wie man vielleicht vermuten möchte. Warum Ext2 auf der IDE-Platte so langsam ist, war nicht festzustellen, wurde aber durch eine Kontrollmessung bestätigt.

Als kleinen Härtetest musste das XFS acht Stunden wüstes Herumkopieren vieler kleiner Dateien ertragen — das tat es ohne irgendwelche Störungen. Ein weiterer interessanter Vergleich: Wie lange dauert es, erstens viele kleine Dateien zu löschen und zweitens eine ganz große (aus /dev/zero gefüllt). Bei der Aktion geht es vor allem darum, wie schnell das Dateisystem die indirekten und mehrfach indirekten Blöcke löscht. Reiser FS mit seiner Baumstruktur nimmt hier für sich in Anspruch, viel schneller zu sein als das Bitmap-orientierte Ext2. Das Ergebnis ist in der Grafik auf der nächsten Seite dargestellt.

Schließlich noch die Frage, wie absturzfest das XFS ist. Als einfacher Test diente ein find|cpio, der den Kernelsource-Baum in das XFS-Dateisystem kopiert. Mittendrin ein kurzer Druck auf Reset — und beim anschließenden Mount zeigt sich, dass das Dateisystem weniger als eine Sekunde für die Reparatur benötigt (siehe Listing, Abschnitt “Kernelmeldungen beim Mount”).

Platzsparend: XFS

XFS braucht im Vergleich zum Reiser FS erheblich weniger Platz für sein Log. Legt man das Dateisystem mit den Defaultwerten an, dann liegt das Log mit auf dem Block-Device. Trotzdem braucht es viel weniger Platz (Listing, Abschnitt “Platzbedarf für das Log”). Bei Reiser FS sind selbst bei einem frisch angelegten Dateisystem bereits etwa 32 MByte fest belegt. Das Logical Volume darunter ist genau 64 MByte groß (siehe Listing, dritter Abschnitt).

Ein weiterer Gimmick: mkfs.xfs bemerkt, wenn in einem Logical Volume bereits ein formatiertes Dateisystem enthalten ist (und zwar nicht nur XFS, es erkennt auch Ext2), und verlangt die Option -f, um trotzdem zu formatieren.

Ob das XFS alltagstauglich ist, müssen weitere Härtetests zeigen — nach dem ersten Anschein sieht es so aus, als halte XFS, was SGI versprochen hat. Ob SuSE übrigens an einem offiziellen Patch für SuSE 7.1 bastelt, war bis Redaktionsschluss nicht zu erfahren — eine entsprechende Anfrage verlief im Sand. Möglicherweise passiert ja auch erst Mitte des Jahres mit Version 7.2 etwas in dieser Richtung.