Anzeigen

Berater Internet Übersetzungsagentur Jobs Günstige Linux Bücher Handy Shop LinuxSoftware

Server, Linux-Software, Hardware, Linux-Bücher Computer & FotoBücherDVDMusikPC- & VideospieleSoftwareVideo

Kleinanzeigen & Preisvergleich Notebook | Drucker | PC Gebrauchtwagen | Münzen Wohnmobile | Grafikkarten Mondorico Suche

Skistiefel - Wörterbuch

Hier kaufen Unternehmen SUSE Linux Computer Festplatten Server Grafikkarten Notebooks Mainboards Router Prozessoren Firewalls Netzteile Switches CD-Brenner Monitore Drucker Displays Scanner Beamer Toner Tastaturen StarOffice Antivirus MS-Office MS-Outlook

Jounaling Filesysteme im Vergleich Buchführung für die Festplatte von Bernhard Kuhn

---

Ein Journaling Filesystem ist ein wesentliches Feature für den baldigen Einstieg von Linux in den Enterprise-Markt. Derzeit gibt es hierfür gleich vier vielversprechende Ansätze in unterschiedlichen Entwicklungsstadien - von nicht existent bis (beinahe) alltagstauglich.

---

Besinnt man sich auf die Server- und Workstationfunktionen, dann ist Linux kaum tot zu kriegen. Wer aber stets die brandheißesten aber wenig getesteten Kernelpatches und Hardwaretreiber haben muss, oder gar selber auf Betriebssystemebene entwickelt, für den sind Systemabstürze keine Seltenheit. Und last but not least kann auch das beste System bei einem Stromausfall ohne USV den Betrieb nicht aufrecht erhalten. Egal welche extremen Umstände Linux in die Knie zwingen: nach dem Neustart ist in aller Regel erst einmal ein Festplattencheck angesagt, der alle Dateien prüft und selten weniger als zehn Minuten beansprucht.

Je nach Größe des Dateisystems und Anzahl der Festplatten kann dieser Vorgang sogar mehrere Stunden dauern. Schlimmer noch: nach einer ungewollten Betriebsunterbrechnung ist in seltenen Fällen sogar ein manueller Eingriff notwendig (fsck). Der - allerding unwahrscheinliche - Daten-GAU ist dann perfekt, wenn sich das Dateisystem nicht mehr reparieren läßt. Spätestens an dieser Stelle hilft nur noch das Einspielen eines (hoffentlich) aktuellen Backups. Dies hört sich jedoch schlimmer an, als es tatsächlich ist: immerhin hat das Extended2-Filesystem seit 1993 treue Dienst für unzählige Linux-Server geleistet, deren seltene "unplaned Downtimes" die potentiellen Mißstände relativiert haben. Dennoch wünschen sich Linux-Anfänger und Profis ein Dateisystem, dass nach einer unsanften Betriebsunterbrechung in jedem Fall ohne menschliche Hilfe und innerhalb von wenigen Sekunden wieder vollständig einsatzbereit ist. Das Zauberwort für die Lösung dieses Problems lautet

Journaling

Das "herkömmliche" ext2-Dateisystem vermerkt beim Anmelden (mounten) lediglich, dass es in Benutzung steht. Dieser Vermerk wird nur bei der ordnungsgemäßen Abmeldung (unmount) gelöscht. Nach einem Crash kann so das Betriebssystem erkennen, ob möglicherweise inkonsistente Daten auf der Platte vorliegen. Um diesen Mißstand zu beheben, müssen nun alle Dateien einzeln überprüft werden - ein mitunter langwieriger Vorgang (Recovery). Dem kann abgeholfen werden, indem stets in einem "Journal" notiert wird, welche Dateien im Augenblick in Bearbeitung stehen, sodass nach einem Ausfall lediglich die betroffenen Files überprüft werden müssen. Bei modernen Dateisystemen findet dabei nicht selten ein transaktionsorientierter Ansatz seine Verwendung: solange eine Vorgang nicht vollständig durchgeführt wurde, behalten die alten Daten der vorangegangenen Transaktion ihre Gültigkeit - dies ist besonders wichtig, wenn ein z.B. ein Schreibvorgang unplanmäßig abgebrochen wird.

Binärbäume

Neben kurzen Wiederherherstellungszeiten zeichnen moderne Dateisysteme auch höhere Zugriffsleistungen aus. Erreicht wird dies durch die Verwendung sogenannter B-Trees anstatt der herkömlichen linearen Anordnung der Datenblöcke. So werden z.B. beim ext2-Dateisystem Verzeichniseinträge in einer verketteten Liste geführt (siehe Abbildung 1). Hat ein Verzeichnis z.B. 1000 Einträge, dann werden im Durchschnitt etwa 500 Suchschritte zur Auffindung ein Datei benötigt, während beim (ausbalanzierten) Binärbaum bereits nach zehn Schritten (ld 1000) das Ergebniss zu Tage tritt (vergleiche Abbildung 1 mit vier Einträgen). Der Performance-Gewinn wird allerdings mit wesentlich komplexerem (und damit fehleranfälligem) Programmcode erkauft. Insbesondere muss nach jedem neuen Eintrag der Binärbaum aufs neue "ausbalanziert" werden, so dass alle Wege von der Wurzel bis zu den entlegensten Blättern etwa gleich lang bleiben. So gesehen sind verkettete Listen völlig entartete Binärbäume. Viele reale Dateisystem-Implementierungen halten sich aber nicht immer strikt an die "reine Lehre" sondern verwenden ein Art Mischform zwischen Listen und Bäumen.

Abb. 1: Verkettete Liste (unten) vs. Binärbaum (oben)

Praxis

Soviel zur grauen Theorie. Die Komplexität von B-Tree- und Journaling-Algorithmen haben eine Umsetzung in die Linux-Realität bislang erschwert. Neben dem herangereiften, frei entwickelten ReiserFS schicken sich nun aber auch IBM und SGI an, ihre alltagsgeprüften und robusten Implementierungen JFS und XFS nach Linux zu portieren. Wer aber bisher mit dem ext2-Dateisystem zufrieden war und lediglich an kurzen Recovery-Zeiten interessiert ist, für denjenigen dürfte sich ein genauerer Blick auf das ext3-fs lohnen.

Tabelle 1: Dateisysteme mit Journaling im Überblick
Name	B-Trees	64-Bit clean	Entwicklungsstand	Lizenz
ReiserFS	Ja	Nein	alltagstauglich mit Einschränkungen	GPL
ext3	Nein	Nein	voll funktionstüchtge Alpha-Testversion	GPL
jfs (IBM)	Ja	Ja	unvollständige preAlpha-Testversion	GPL
xfs (SGI)	Ja	Ja	noch nicht veröffentlicht	GPL (geplant)

ext3-fs

Das ext3-fs ist lediglich eine Erweiterung des bekannten ext2-fs um Journaling-Funktionalität und verzichtet auf leistungssteigernde Binärbäume. Dafür können existierende Linux-Installationen auf ext2-Basis ohne Neuinstallation oder zeit- und plattenplatzraubenden Umkopieraktionen unmittelbar weiterverwendet werden, da ext3 auf die bestehenden Strukturen aufbaut [1]. Noch dazu ist für fortgeschrittene Linux-User die Installation und Inbetriebnahme nicht sonderlich kompliziert (siehe Rezept 1). Allerdings ist ext3fs laut dem Hauptentwickler Stephen Tweedie erst im Alpha-Teststadium und noch lange nicht für den Alltagseinsatz geeignet. Dennoch häufen sich in Newsgruppen und anderen Internetforen positive Rückmeldungen. Auch ein Kurztest in unserem Hardwarelabor zeigte keine Schwächen. Dabei darf man aber auch nicht nicht vergessen, dass Alpha-Testversionen bei Linux von der Marketing-Abteilung so manch anderer Betriebssysteme bereits als Version 1.0 angeprisen würden.

Rezept 1: ext3fs-Nachrüstung

Ein bestehendes ext2-Dateisystem mit Journaling-Fähigkeiten auszustatten ist Dank dem abwärtskompatiblen ext3-fs für den fortgeschrittenen Linux-User beinahe ein Kinderspiel. Linux-Einsteiger haben lediglich die Hürde der Kernel-Kompilation und Installation zu meistern. Selbstverständlich empfiehlt sich dringend ein Backup aller wichtigen Dateien vor dem nicht ganz ungefährlichen Eingriff. 1. Zunächst benötigt man einen "unbehandelten" Kernel und den ext3-Patch. Für den Kernel 2.2.12 der RedHat 6.1 enthält das ext3-Packet einen gesonderten Patch, so dass der 14MB-Kernel-Download bei Verwendung dieser Distribution entfallen kann. cd /tmp wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.gz wget ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/ext3-0.0.2c.tar.gz 2. Nun muss der Kernel entpackt, gepatcht, konfiguriert und installiert werden. Die auftretenden Warnungen beim Patchen können übrigens ignoriert werden. Nicht vergessen: bei der Kernelkonfiguration muss in der Sektion Filesystems die Option Second extended fs development code für das ext3 aktiviert sein. Nach der Installation des Kernels sollte mit einem Reboot zunächst sichergestellt werden, dass das System noch wie gewohnt anläuft. cd /usr/src rm linux # alten link löschen tar -xzf /tmp/linux-2.2.13.tar.gz tar -xzf /tmp/ext3-0.0.2c.tar.gz cd linux patch -p1 < ../ext3-0.0.2c/linux-2.2.13-ext3.diff make menuconfig make clean && make dep && make bzImage make modules && make modules_install # Kernel nach /boot umkopieren und per LILO installieren 3. Ab jetzt können alle Nicht-Root-Partitionen in ext3-Dateisysteme umgewandelt werden. Dazu muss der Benutzer von Hand eine Journal-Datei auf der Partition anlegen und initialisieren. Je nach Betriebsamkeit sollte das Journal eine Größe von ca. zehn bis 30 MB aufweisen. Für die Initialisierung wird die Inode-Nummer, die das Journal auf der Partition repräsentiert, benötigt. Diese Zahl verrät der Befehl ls mit der Option "-i". In folgendem Beispiel ist /usr eine gemountete ext2-formatierte Partition (/dev/hda4). # in /etc/fstab für den /usr-Eintrag die # Dateisystemkennung ext2 durch ext3 ersetzen vi /etc/fstab # /usr unmount vorbereiten (sonst "busy") init 1 # Journal anlegen (30MB) dd if=/dev/zero of=/usr/journal.dat bs=1k count=30000 # Inode-Nummer ermitteln (hier z.B. 666) ls -i /usr/journal.dat 666 /usr/journal.dat # /usr als ext3-fs mounten und Journal mit # ermittelter Inode-Nummer initialisieren umount /usr mount -t ext3 /dev/hda4 /usr -o journal=666 Soweit so gut, aber leider ist obige Methode nicht auf die Root-Partition anwendbar, da diese nicht mitten im Betrieb abgemeldet werden kann. Das Henne-Ei Problem löst sich, indem die Journal-Initialisierung als Kernel-Bootoption angegeben wird. Doch alles der Reihe nach: 4. Analog nach obigem Beispiel muss dem Rechner in /etc/fstab für die künftigen Systemstarts mitgeteilt werden, dass das Root-Filesystem fortan ein ext3-fs sein soll. (ext2 beim /-Eintrag durch ext3 ersetzen). 5. Das Journal wird (wie oben) von Hand auf der Root-Partition angelegt und beim nächsten Systemstart muss die Inode-Nummer (hier 7777) des Journals als Kernel-Parameter übergeben werden. dd if=/dev/zero of=/journal.dat bs=1k count=30000 ls -i /journal.dat 7777 /journal.dat reboot Der Rechner startet nun neu und beim erscheinenden LILO-Prompt müssen ein paar zusätzliche Kerneloptionen inkl. Inode-Nummer des Journals für dessen Initialisierung übergeben werden: LILO: linux ext3 rw rootflags=journal=7777 Die Root-Partition steht nun auch nach einem harten Reset binnen weniger Sekunden Wiederherstellungszeit zur Verfügung (oder sollte es zumindest). Der ganze Vorgang kann übrigens wieder rückgängig gemacht werden, indem ext3 in /etc/fstab durch ext2 ersetzt wird.

ReiserFS

Was einst als privaten Studie des Dateisystemspezialisten Hans Reiser begann, entwickelte sich bis heute zu einem alltagstauglichen und leistungsstarken Dateisystem [2]. Die Untersuchungen und Experimente sind aber noch nicht gänzlich abgeschlossen und es wird ständig weiter nach möglichen Optimierungsmassnahmen geforscht -- mittlerweile sogar im Auftrag der SuSE GmbH.

Das ReiserFS ordnet Dateien und Verzeichniseinträge in Binärbäumen. Kleine Dateien bzw. Dateireste (tail ends), Verzeichniseinträge und Verweise auf gewöhnliche 4K-Dateiblöcke (Unformated Nodes) werden gemischt (items)in 4K-Blöcken (Formated Nodes) untergebracht um den vorhandenen Plattenplatz optimal zu nutzen (vgl. Abbildung 2). Ein erfreulicher Nebeneffekt dieser Konzentration ist, dass sich dadurch auch mehr Informationen im Buffer-Cache befinden und deshalb weniger "echte" Plattenzugriffe nötig sind. Beim ReiserFS wird auch stets darauf geachtet die Daten in der Nähe ihrer Verweise und Verzeichniseinträge zu halten um große Bewegungen des Schreib/Lesekopfes zu vermeiden.

Abb. 2: Die Struktur des ReiserFS (vereinfacht) in UML-Notation

All diese Finessen liessen den Quellcode (30k LOC) auf den fünffachen Umfang des ext2-Dateisystems anwachsen und trotzdem (oder gerade deshalb) sind dem ReiserFS derzeit noch einige Einschränkungen auferlegt: es sind nur 4k-Blöcke erlaubt und der Einsatz von SoftRAID ist gänzlich verboten. Andere Hardware-Plattformen als x86 sind ebenfalls ausgeschlossen. ReiserFS verträgt sich übrigens auch nicht mit dem ext3-Patch (wegen Überschneidungen bei der Namensgebung!), aber dafür mit RT-Linux 2.0, wie auf dem letztjährigen RT-Linux Workshop in Wien bewundert werden konnte: hier ist die Nachfrage von Seiten der Entwickler nach kurzen Recovery-Zeiten besonders hoch, da jeder kleine Programmierfehler während der Entwicklung auf RT-Ebene beinahe ausnahmslos mit einem Systemabsturz geahndet wird.

Leider ist die Inbetriebnahme des ReiserFS wesentlich kompilizierter als bei ext3. (siehe Rezept 2). Alternativ zur aufwändigen manuellen Installation kann man bei SuSE 6.3 die CD1 nach Anleitung des Distributors [3] auf einen Rechner kopieren und dann den Patch (Vorsicht: mehr als 50MB) einfahren (in der Version 6.4 wird ReiserFS dann offiziell aufgenommen, zu 6.3er-Zeiten waren noch kleinere Unstimmigkeiten bekannt, die einen Mission Critical Einsatz nicht zuließen). Dannach erfolgt die Installation wie gewöhnlich per NFS oder mit der "zurückgebrannten" CD.

Im Redaktionsalltag hat sich dieses Dateisystem schon seit über drei Monaten bestens auf der Workstation des Hardwareredakteurs und einem Notebook bewährt -- tägliche Backups aller wichtigen Daten auf einen NFS-Server (mit altgedientem ext2fs und Bandlaufwerk) ist für den Fall eines Falles ohnehin Pflicht.

Rezept 2: ReiserFS-Umrüstung

Wer seinen Rechner auf ReiserFS umrüsten möchte, hat derzeit noch ein gutes Stück Arbeit vor sich. Wie auch bei der ext3-Nachrüstung ist der Vorgang nicht ganz ungefährlich, aber da das bestehende System im Laufe der Umrüstung umkopiert werden muss, erübrigt sich ein Backup - vorrausgesetzt man macht keine Fehler beim Repartitionieren und verfügt über eine geeignete Boot-Diskette für den Fall eines verkonfiguierten LILO. Als Vorbereitung wird eine freie Partition benötigt, welche groß genug sein muss um die bestehende Linux-Installation aufnehmen zu können. (selbstverständlich kann das System auch aus mehreren Partitionen bestehen). Außerdem wird zusätzlich eine ca. 30 MB große /boot-Partition (mit ext2-Dateisystem) benötigt, da der LILO mit einem auf einem ReiserFS befindlichen Kernel nicht klarkommt. /boot wird im Normalbetrieb Read-Only angemeldet, so dass nach einer unsanften Betriebsunterbrechung keine fsck nötig ist. Doch nun Schritt für Schritt: 1. Zunächst werden die Kernel-Quellen und der Patch für das Journaling-ReiserFS benötigt. Achtung: es gibt auch ein ReiserFS ohne Journaling! cd /tmp wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.2/linux-2.2.14.tar.gz wget http://devlinux.com/pub/namesys/linux-2.2.14-reiserfs-3.5.16-patch.gz 2. Kernel entpacken, patchen, konfigurieren und installieren (Achtung: Option Filesystems/ReiserFS bei der Konfiguration nicht vergessen) cd /usr/src rm linux # alten link löschen tar -xzf /tmp/linux-2.2.14.tar.gz cd linux gzip -cd /tmp/linux-2.2.14-reiserfs-3.5.16-patch.gz | patch -p1 make menuconfig make clean && make dep && make bzImage make modules && make modules_install # Kernel nach /boot umkopieren und per LILO installieren 3. Nach dem Neustart können nun die Werkzeuge (insbesondere mkreiserfs) angefertigt werden: cd /usr/src/linux/fs/reiserfs/utils mkdir bin && make cp bin/mkreiserfs /sbin 4. Anlegen der neuen Dateisysteme und Umkopieren der Daten: In folgendem Beispiel sei /dev/hda2 die derzeitig Root-Partition (inkl. /boot), /dev/hda6 die künftige (journaled) Root-Partition und /dev/hda5 die künftige /boot-Partition (ext2, ro). Das jungfräulische journaling ReiserFS belegt nach Formatierung bereits etwa 30 MByte für das Journal. # System in "sichern" Modus bringen init 1 # Root-Partition umkopieren mkdir /tmp/newroot mkreiserfs /dev/hda6 mount /dev/hda3 /tmp/newroot (cd / && tar cplf - . --exclude boot) | (cd /tmp/newroot && tar xpf -) # /boot umkopieren mkdir /tmp/newboot mke2fs /deb/hda5 mount /dev/hda5 /tmp/newboot (cd /boot && tar cpf - . ) | (cd /tmp/newboot && tar xpf -) 5. Anpassen der fstab. Statt ext2 für root muss nun reiserfs angegeben werden. Außerdem hat sich die Root-Partition verschoben (hda2 nach hda5). Zusätzlich darf der Eintrag für die neue /boot-Partition nicht vergessen werden. Also: Statt des alten /etc/fstab-Eintrag für obiges Beispiel /dev/hda2 / ext2 defaults 1 1 muss der relevante Teil der neuen /tmp/newroot/etc/fstab etwa wie folgt aussehen: /dev/hda5 / reiserfs defaults 1 1 /dev/hda6 /boot ext2 ro 0 0 6. Ob nun der umfangreiche Umzug geglückt ist, wird am besten mit einer Bootdiskette gefahrlos überprüft. So bleibt der heikle Master Boot Record zunächst unberührt: # Bootdiskette erstellen dd if=/usr/src/linux/arch/i386/boot/bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda6 # neue Root-Partition festlegen sync && reboot Nachdem der Rechner (hoffentlich) in das umkopierte System gebootet hat, bleibt nurmehr die Anpassung von /etc/lilo.conf auf die neuen Verhältnisse. Vor dem Aufruf von LILO muss allerdings die /boot-Partition schreibbar gemounted werden, da sich lilo sonst beschwert: mount -o remount,rw /boot

XFS

Bereits vor etwa einem Jahr hat SGI angekündigt ihre "Kronjuwelen" unter GPL-Bedingungen für Linux zur Verfügung zu stellen. Im Gegensatz zu den anderen zahlreichen und erfolgreichen Open Source Projekten von SGI kommt das XFS nur schleppend vorran - dies liegt unter anderem daran, dass es eben noch gar nicht "offen" ist: noch sind SGIs Programmierer damit zu Gange fremdes geistiges Eigentum aus dem Quellcode zu entfernen und gegen eigene Reimplemtierungen zu ersetzen. Bleibt zu hoffen, dass bei dieser radikalen Maßnahme nicht die Robustheit des Codes in Mitleidenschaft gezogen wird. Im Frühjahr soll dann erster Quellcode erhältlich sein und im Sommer - so alles gut geht - wird Linux-XFS laut SGI für den operationellen Einsatz tauglich sein [4]. Man darf also gespannt sein.

JFS

Das Journaling File System von IBM für Linux wurde überraschend auf der diesjährigen Linux World Expo in New York angekündigt. Die derzeit erhältliche Version 0.0.1 ist aber noch in einem sehr frühen Entwicklungsstadium - mehr als ein schlichtes ls auf einem gemountetes JFS ist nicht drin. Dafür aber ist der robuste alltagserprobte Quellcode verfügbar, so dass eine schnelle Komplettierung sehr warscheinlich sein dürfte. Leider enthält das etwa 1,3 Megabyte große tgz-Packet [5] nur spärliche Dokumentation, aber ein Blick in den Quellcode verrät, dass auch das JFS intensiven Gebrauch von Binärbäumen macht und 64bit-clean zu sein scheint.

Fazit

Vier vielversprechende Ansätze für Journaling wecken große Hoffnungen auf einen baldigen Aufstieg von Linux in höhere Sphären. Aber nicht nur für Enterprise-Server ist dieses Feature wichtig, sondern auch für den rasant wachsenden Embedded-Linux Markt (hier werden oft sogar bewußt Rechner einfach abgeschaltet). Mit XFS und JFS gehen zwei aus kommerziellen Produkten entstandene Projekte in Rennen. Der existierende und robuste Code wird derzeit von den Firmen für Linux auf Vordermann gebracht. Allerdings haben das leicht installierbare ext3 und insbesondere das ReiserFS einen ganz klaren Vorsprung. Letzteres wird sogar von dessen Entwickler als produktion stable bezeichnet, was zumindest bei unserem dreimonatigen Workstation-Betrieb bestätigt werden kann. Dennoch werden immer wieder Bedenken laut, dass das ReiserFS noch nicht allumfassend getestet sei. Dies kann nur durch eine breite Nutzerschafft sichergestellt werden. Die nachträgliche Installation ist zwar nicht ganz einfach aber dafür sehr lehrreich und später auch sogar hilfreich.

Infos

[1] Ext3-Download: ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs [2] ReiserFS-Homepage: http://devlinux.com/projects/reiserfs/ [3] ReiserFS-Installationsanleitung von/für SuSE: http://sdb.suse.de/sdb/de/html/tw_reiser.html [4] XFS-Homepage:http://oss.sgi.com/projects/xfs/ [5] JFS-Homepage: http://oss.software.ibm.com/developerworks/opensource/jfs/index.html

Copyright © 2000 Linux-Magazin Verlag

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.