....ohne vorheriges Herunterfahren hatte bislang bekanntlich zur Folge, daß beim nächsten Booten des Systems der unvermeidliche Filesystem-Check sich anschickte, sämtliche zu mountenden ext2-Partitionen hinsichtlich eventueller Fehler zu überprüfen. Normalerweise nur ein lästiger, weil bei großen Laufwerkskapazitäten enorm zeitaufwendiger Prozeß, hatte dieser Check doch auch hin und wieder zur Folge, daß sich ein Filesystem als stark inkonsistent erwies, was im ungünstigsten Falle auch schon mal mit einem mke2fs endete. Mindestens ebenso lästig erwies sich im Hinblick auf den FS-Check die Tatsache, daß dieser zudem noch an eine maximale Anzahl von Mounts oder aber eine bestimmte Zeitspanne (Standard: 6 Monate) gebunden war. All dies ist generell nur lästig, kann aber im Hinblick auf High-Availability-Server, die auch im Falle eines wie auch immer verursachten Absturzes enorme Unannehmlichkeiten mit sich bringen.
Beispielsweise wenn die Hälfte eines Unternehmens über einen längeren Zeitraum nicht auf ihre Dateien zugreifen kann, weil der Fileserver noch im Bootvorgang beschäftigt ist (der unter Umständen noch weitere Katastrophen mit sich bringt, siehe oben...).

Entsprechend ist der Ruf nach einer Alternative berechtigt und eine angemessene Lösung für derlei Probleme scheint der Einsatz eines sogenannten Journaling-Filesystems zu sein. Wie vielleicht bekannt ist, rühren die meisten der diesbezüglichen Probleme mit dem ext2-System daher, daß das Betriebssystem Daten aus geöffneten Dateien nicht sofort auf die Platte schreibt, sondern aus Effizienzgründen zunächst in einem Zwischenspeicher hält und dann erst später auf das Speichermedium bringt (die Platte wird synchronisiert). Es ist entsprechend leicht vorstellbar, daß nach einem Crash kurz vor einer solchen Synchronisation einige (die geöffneten und noch nicht wieder geschriebenen) Dateien in einem zweifelhaften Zustand sind, was letztlich dazu führt, daß im Verlauf des nächsten Bootvorganges, bzw. genauer gesagt der Filesystem-Prüfung, jede der Dateien auf dem Filesystem auf Inkonsistenz untersucht werden muß.

Genau hier setzt das Journaling-Filesystem ein: In einem sogenannten "Journal" wird jederzeit festgehalten, welche Dateien in Verwendung bzw. geöffnet sind. Damit ist im Falle eines Ausfalls klar, welche Dateien inkonsistenzgefährdet sind und damit überprüft werden müssen. Leicht vorstellbar, daß der FS-Check und eventuelle Recovery-Maßnahmen deutlich schneller vonstatten gehen...

Auf diversen kommerziellen Unix-Systemen sind Journaling Filesystems längst gang und gäbe (man beachte nur das IRIX von SGI, deren Dateisystem, das XFS, mittlerweile auch zur Freude von Teilen der Linux-Gemeinde, auf GPL-Basis umgearbeitet wird), doch auch im Linux-Sektor findet man mittlerweile einige interessante Ansätze. Gegenwärtig der wohl am weitesten diskutierte und auch ausgereifteste Vertreter dieser Zunft ist das von Hans Reiser entworfene und mittlerweile unter Finanzierung von SuSE weiterentwickelte reiserfs. Es verspricht neben den Journaling-Aspekten auch Performance-Gewinne durch eine moderne Art der Plattenverwaltung.
Zeit also, diesem Testkandidaten einmal auf den Zahn zu fühlen ...

Zunächst fällt auf: Der Weg zum Linux-System auf ReiserFS-Basis ist momentan (will man sich nicht gerade mit der aktuellen SuSE-Distribution herumschlagen, die eine Installation direkt in dieses Filesystem hinein anbietet) noch relativ lang und unbequem und sieht in den Grundzügen so aus:

• Der verwendete Kernel muß auf ReiserFS-Fähigkeit gepatcht  und kompiliert werden (im Test wurde 2.2.14 verwendet), danach sollte man die ReiserFS-Tools (insbesondere mkreiserfs) kompilieren und ins System bringen. Der Griff ans System ist hier unumgänglich. Schlechte Karten haben somit all jene, die auf out-of-the-box-Kernels schwören und eine Eigenkonfiguration scheuen.
• Es müssen neue Partitionen angelegt und mit ReiserFS formatiert werden, eine für jedes Filesystem, welches von ext2 nach Reiser konvertiert werden soll. Wenn das Root-Filesystem auf ReiserFS geführt werden soll, ist zudem eine als ext2 formatierte /boot - Partition anzulegen. LILO erlaubt es momentan nicht, wenn der Kernel auf einem ReiserFS-Dateisystem liegt.
• Schließlich und endlich müssen sämtliche Daten aus den alten ext2-Systemen in die Reiser-Systeme kopiert werden. Danach wird das System an die neuen Gegebenheiten angepaßt (fstab editieren, LILO gegebenenfalls neu konfigurieren usw.), neu gebootet, und dann heißt es hoffen bzw. beten, daß die Programme und die Daten den brachialen Eingriff heil überstanden haben.

Trotz (oder gerade wegen?) der unhandlichen Installation galt es also einen Versuch zu unternehmen, auf diesem Wege ein brauchbares Resultat zu erhalten. Allerdings wurde hierbei nicht der Weg gegangen, ein bestehendes System auf Reiser umzustellen, sondern auch gleich einmal eine komplette Neuinstallation durchzuführen. Als Distribution fand das von mir momentan favorisierte Stampede Linux 0.89 Verwendung. Und dann konnte es auch schon losgehen...

Die Plattenaufteilung meiner vorherigen Installation wurde weitestgehend beibehalten (separate Partitionen für /, /home und /usr , insgesamt etwa 7 GByte), dazu kamen noch eine /boot- und eine Installationspartition für das Basissystem.

Problemlos die Installation des Systems: Wie bei Stampede üblich, Booten mit einer Boot- und einer Root-Diskette, danach Formatieren der Installationspartition und eine längere, mit der Lektüre von William Gibsons "Idoru" verbrachte Zwangspause, während der Installer die *.slp - Pakete des Systems auf die Festplatte brachte. Da (was sonst wäre auch zu erwarten ;) ) mein gesamter Mail- / Usenet- / Webzugriff im Linux stattfindet und ich nicht recht im Klaren war, was ich von der ReiserFS-Installation zu erwarten hatte, war die Entscheidung an diesem Punkt der Installation die, das System komplett einzurichten, die benötigte Software einzuspielen und einen reibungslosen Betrieb im normalen Umfeld zu ermöglichen. Danach eine Kopie des so erreichten Arbeitssystems in die ReiserFS-Partitionen zu schieben und zu prüfen, ob diese den Ansprüchen gerecht wird.

Der nächste logische Schritt war, das System erst einmal zu aktualisieren und gleichzeitig ReiserFS-tauglich zu machen. Dies bedeutete:

• aktuelle Kernelquellen (2.2.14) besorgen und Richtung /usr/src/linux entpacken
• ReiserFS-Patch aus dem Netz laden (zum Zeitpunkt der Installation Version 3.5.19) und der Einfachheit halber unter /usr/src ablegen, gegebenenfalls entpacken
• Einspielen des Patches in den Kernel-Tree
• Aktivieren der ReiserFS- Unterstützung im Kernel
• Kompilieren des neuen Kernels
• Kopieren des neuen Kernels  gen /boot und Neukonfiguration und -installation von LILO
• Erzeugen der ReiserFS- Utilities, die sich unter /usr/src/linux/fs/reiserfs/utils finden, und Kopieren der Binaries nach /sbin

That's it, für den Moment. Nach einem Neubooten des Systems sollte, wenn alles nach Wunsch verlaufen ist, die Ausgabe von

>> cat /proc/filesystems

Nun zum eigentlich etwas kritischen Teil der Installation, dem

Zunächst jedoch wieder einige Vorbereitungen: Mittels "mkreiserfs" wird auf den entsprechenden Partitionen ein Dateisystem angelegt, im Falle meiner Beispiel-Installation waren das /usr und / (/home blieb sicherheitshalber vorerst auf ext2 ).
Gleichermaßen wird die /boot-zu-werdende Partition mit "mke2f s" formatiert. Weiterhin entschloß ich mich, die (im weiteren Verlauf nicht unwesentliche) Datei /etc/fstab ins /root-Verzeichnis zu kopieren und die Kopie den neuen Gegebenheiten (sprich: für die Startbarkeit des neuinstallierten Systems) entsprechend einzurichten.  Weiterhin wurde in /etc/lilo.conf eine weitere Sektion angefügt, um die neue Root-Partition dann auch booten zu können, und die neue LILO-Konfiguration wurde neu installiert.

Derart gewappnet, stand der langwierigen Kopiererei nichts mehr im Wege:

Der Reihe nach wurden / , /usr (jeweils mit "-t reiserfs") und /boot (wie gehabt mit "-t ext2") an /mnt gemounte t und jeweils die entsprechenden Dateien (wahlweise mittels "cp" oder einer Pipe mit "tar", z.B.

>> (cd / && tar cplf - . --exclude boot --exclude usr) | ( cd /mnt && tar xpf - ) 

Abschließend (etwa 15 Seiten aus "Idoru" später...) wurde die vorher unter /root abgelegte modifzierte fstab Richtung /mnt/etc an ihren neuen Platz gebracht und das System neu gebootet.

....verlief dann auch gänzlich unspektakulär: Abgesehen von einigen kleinen Flüchtigkeitsfehlern in der /etc/fstab bootete das kopierte Betriebssystem schnell und problemlos bis zum Login-Screen. Ein Blick auf /etc/mtab zeigte:

thunderbird:cat /etc/mtab
/dev/hdb1 / reiserfs rw 0 0
/dev/hda3 /usr reiserfs rw 0 0
/dev/hdb2 /boot ext2 ro 0 0
/dev/hda10 /home ext2 rw 0 0
/none /dev/pts devpts rw,gid=5,mode=620 0 0
proc /proc proc rw 0 0

Selbst Brachialtests konnten das System nicht aus der Ruhe bringen: Ganz gleich, bei welcher Aktivität der Systemabsturz durch Betätigung der Reset-Taste simuliert wurde (Beispiel: Berechnen eines TeX-Dokuments mit gerade aktivem Metafont, Kopieren des /usr/doc - Verzeichnisses nach /tmp usw.) langwierige Plattenprüfungen blieben aus, das System bootete immer etwa gleichschnell und problemlos. Die langen Wartezeiten, die ext2 in solchen Situationen sichergestellt hätte, fehlten ebenso wie der Sprung in den Single-User-Runlevel zur Reparatur einer Partition.

Mittlerweile läuft ReiserFS knapp einen Monat auf meinem System, und bislang sind die Ergebnisse ausgesprochen befriedigend. Es bliebe zu testen (sprich: zu messen), wie die neben dem Journaling angepriesenen Performance- Gewinne durch die verbesserte Plattenorganisation ins Gewicht fallen, und wie das Filesystem nach längerem Betrieb aussieht. Die erste Probe hat das ReiserFS jedenfalls bestanden...

.... zum reiserfs gibt es indes gleich mehrere: Da wäre zunächst ext3 als logischer Nachfolger des gegenwärtigen ext2-Dateisystems, der sich den Entwicklern zufolge noch im frühen Alpha-Stadium befindet und somit auch noch nicht für den Einsatz in einer 'produktiven' Umgebung in Frage kommt. Vorteilhafterweise ist hier zu bemerken, daß die (oben geschilderte) Kopiererei der installierten Distribution beim Umstieg von ext2 auf ext3 entfällt (lediglich das Journal für jede ext3-zu-werdende Partition muß manuell eingerichtet werden) und der Schritt entsprechend einfach wieder rückgängig zu machen ist, so daß ein Test dieses Systems in naher Zukunft ebenfalls realisiert werden wird. Der experimentierfreudige Linuxer sei jedoch gewarnt, reiserfs und ext3 in denselben Kernel-Tree einzuspielen, durch diverse Gleichheiten bei der internen Namensgebung wäre mit schwerwiegenden Problemen zu rechnen.
Weiter zu erwähnen ist das oben erwähnte XFS-System von SGI. In aller Eindeutigkeit: XFS ist von allen hier angeführten Ansätzen zum Journaling Filesystem die mit Abstand robusteste und bewärteste Alternative, die zudem auch ( eben im Rahmen von SGI's IRIX-System ) schon etliche Praxis-Jahre auf dem Buckel hat. Allerdings ist XFS erst seit kurzem Open-Source, gegenwärtig wird daran gearbeitet, den Source-Code diesbezüglich umzuarbeiten, dabei eventuell verwendete Patente und ähnliches zu entfernen und die entsprechenden Funktionen neu zu implementieren. Es bleibt zu hoffen, daß die daraus entstehenden Quellen den hohen Level der proprietären Version halten können.
Die letzte, vermutlich jüngste Entwicklung in dieser Reihe, JFS von "Big Blue" IBM, gegenwärtig in der Version 0.0.1, ist leider noch nicht weit genug gediehen, um eine alltagstaugliche Verwendung einer entsprechend formatierten Festplatte zu ermöglichen: die Fähigkeiten des neuen Systems sind gegenwärtig auf ein simples 'ls' beschränkt. Letztlich wird die Zeit zeigen, welcher der Ansätze als erster im großen Rahmen zum Einsatz kommen wird. Entwicklungs- und Testarbeit ist bei allen noch vonnöten, doch zum gegenwärtigen Zeitpunkt ist reiserfs eindeutig am weitesten.

Links und Informationen:

www.linux-magazin.de	Homepage des Linux-Magazins, in dessen Ausgabe 4 / 2000 ein umfassender Artikel von Bernhard Kuhn zu diesem Thema verfasst wurde und der dem Leser in Sonderheit mehr über technische Details sowie über das (hier nicht behandelte) ext3- System bietet.
http://devlinux.com/projects/reiserfs	ReiserFS-Page. Hier findet man die Patches, Grundlagen und jede Menge andere Dokumentation
ftp://ftp.de.kernel.org/pub/linux	FTP-Server zum Download des aktuellen Linux-Kernel
http://oss.sgi.com/projects/xfs	SGI-Homsite für das XFS.
http://oss.software.ibm.com/developerworks/opensource/jfs/index.html	Homepage des JFS
ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs	Download-Site für alle ext3-Interessierten.