Open Source im professionellen Einsatz
Linux-Magazin Online Artikel/
www.photocase.com

www.photocase.com

Journaling-Dateisysteme unter Linux

Beschränktes Schreiben

01.10.2006

Journaling-Dateisysteme versprechen, ihre Integrität auch bei Systemausfällen zu bewahren - tatsächlich klappt das aber nur unter bestimmten Bedingungen. Zuerst muss der Admin dafür sorgen, dass die Voraussetzungen stimmen.

970

Das Dateisystem hat keinen spektakulären Job: Unzählige Male im Computerleben besorgt es seinem Rechner Daten oder legt sie für ihn ab. Dabei malocht es beharrlich, aber kaum beachtet im Hintergrund - zumindest, solange nichts passiert. Im Fehlerfall nämlich offenbart sich sofort: Alles hängt von ihm ab, oh-ne seine Dienste ist der PC ein hilfloser Haufen Blech. Spätestens jetzt ist der Admin gut beraten, der weiß, wie die Datenablage hinter den Kulissen genau zu Werke geht.

Dieses Wissen kann man leicht schnel-ler benötigen, als einem lieb ist. So hatte der Autor auf seinem IBM ThinkPad T23 mit Kernel 2.6.16, XFS und aktiviertem Schreibpuffer der Festplatte mit drei Da-teisystem-Crashes innerhalb einer Woche zu kämpfen [1]. Bei deaktiviertem Schreibcache gab es mit dem gleichen Kernel keinerlei Probleme - frühere Kernelversionen waren allerdings auch mit Schreibpuffer stabil gelaufen. Schließlich brachte ein neuer Kernel 2.6.17 und dessen Write-Barrier-Funktionalität die Stabilität zurück. Dieser Beitrag erklärt, was es mit den hilfreichen Schreibbarrieren auf sich hat.

So funktioniert Journaling

Journaling-Dateisysteme, zu denen auch das XFS im Beispiel gehört, bieten ihren Daten eine besondere Lebensversicherung, indem sie über jedwede Änderung penibel Buch führen.

Dabei kann man grundsätzlich zwei Vorgehensweisen unterschieden: Metadaten-Journaling garantiert die Konsistenz der Dateisystem-Struktur, während das langsamere Daten-Journaling (oder Full Journaling) auch die Konsistenz der Dateiinhalte gewährleistet (siehe Kasten "Daten-Journaling"). Unter Metadaten versteht man in diesem Zusammenhang alle Informationen über gespeicherte Dateien und Verzeichnisse wie Datei- und Verzeichnisnamen, Dateigrößen, Rechte und den Speicherort. Solche Informationen speichert das Dateisystem in speziellen Blöcken für Verwaltungsinformationen, den Inodes (siehe Artikel ab Seite 80).

Daten-Journaling

Ein Journaling-Dateisystem, das nur Metadaten ins Journal aufnimmt, hat einen Nachteil: Nach einem abrupten Abbruch der Schreib-Aktivitäten enthalten Dateien nach unvollständigen Schreibvorgängen mitunter Müll [14]: So hatte das Dateisystem vielleicht weitere Datenblöcke für die Datei reserviert, bevor Schreibvorgänge in diese Blöcke abgeschlossen waren. Oder ein Schreibvorgang, der Daten in einer Datei überschreiben sollte, war noch aktiv.

Ein Dateisystem mit Daten-Journaling schafft hier Abhilfe, indem es auch die eigentlichen Daten zuerst in das Journal schreibt. Bei einem unvorhergesehenen Abbruch stellt das Dateisystem anhand der Informationen aus dem Journal wieder einen konsistenten Zustand her, bei dem Metadaten und Daten in den Dateien zusammenpassen und einzelne Schreibvorgänge abgeschlossen sind oder nicht stattgefunden haben.

Die Dateisystem Ext3, ReiserFS 3 und Reiser 4 unterstützten Daten-Journaling. XFS und JFS hingegen bislang nicht.

Schreibvorgänge sind bei aktiviertem DatenJournaling deutlich langsamer, da alle Schreibvorgänge doppelt stattfinden. Daten landen zuerst im Journal und erst dann am eigentlichen Punkt auf der Festplatte. Einzig Reiser 4 bietet die Möglichkeit, die Daten sofort an ihren Bestimmungsort zu schreiben und dabei ein wanderndes Journal über diese Daten zu legen [15].

Die Dateisysteme Ext3 und ReiserFS 3 bietet eine Zwischenlösung, welche ohne Daten-Journaling auskommt: Das Dateisystem schreibt die zur einer bestimmten Metadaten-Transaktion gehörenden Datenblöcke, bevor es die Transaktion in das Journal schreibt. Die neu reservierten Datenblöcke einer Datei enthal-ten damit immer gültige Daten. Ein nur halb vollendeter Vorgang, der Daten in einer Datei überschreibt, hinterlässt allerdings immer noch einen inkonsistenten Zustand.

Selbst beim Daten-Journaling sind Anwendungsdaten nicht automatisch sicher, falls der Schreibprozess ein abruptes Ende findet. Deshalb verfügen viele Datenbanken und Server-Programme wie Mailserver über eigene Me-chanismen, um auch bei einem Systemab-sturz oder Stromausfall die Integrität der Daten zu gewährleisten.

Dieses anwendungsbezogene Daten-Journa-ling basiert in der Regel ebenfalls darauf, Daten in einer bestimmten Reihenfolge zu schreiben und auf unteilbare Schreibvorgän-ge zurückzugreifen. Einen anderen Weg schlagen Programme wie die KDEPIM-Anwendungen KAddressBook, KOrganizer und Akkregator ein. Sie legen von wichtigen Dateien selbständig Backups an.

Wird das Dateisystem beim Ändern der Metadaten unterbrochen, gerät es leicht in einen inkonsistenten Zustand, weil die meisten Änderungen aus mehreren Schritten bestehen, die nun womöglich erst zur Hälfte absolviert wurden. So muss das Dateisystem beim Anlegen eines neuen Files einen Verzeichniseintrag erstellen, Speicherplatz reservieren, die Daten schreiben und sich ihren Ablageort merken. Bei einem abrupten Abbruch ist nun vielleicht der Speicherplatz der Datei reserviert, allerdings kein Verzeichniseintrag erstellt, oder umgekehrt, je nachdem, welche Informationen es noch auf die Festplatte geschafft haben.

Ein Dateisystem ohne Journal-Funktion weiß nach dem Neustart nur, dass es nicht ordentlich abgemeldet wurde. Ob die Metadaten durcheinander geraten sind, muss in diesem Fall ein spezialisiertes Programm wie »fsck« überprüfen. Bei großen Dateisystemen mit vielen Verzeichnissen sowie Dateien kann das sehr lange dauern.

Atomisch schreiben

Ein Journaling-Dateisystem hingegen schreibt die Änderungen für einen kompletten Vorgang wie das Anlegen einer Datei zunächst als eine Transaktion in sein Journal (Abbildung 1). Eine Transaktion ist ein atomischer, also unteilbarer Vorgang, der zwei Zustände kennt: komplett abgeschlossen oder nicht stattgefunden. Ist eine Transaktion vollständig, markiert das Dateisystem sie in einem unteilbaren Schreibvorgang.

Abbildung 1: Das Dateisystem schreibt einzelne Transaktionen hintereinander in das Journal. Vollständige geschriebene Transaktionen markiert es in einem unteilbaren Schreibvorgang.

Für das Journal gibt es zwei grundlegende Speicherformate: Ein physisches Journal, wie es Ext3 verwendet, nimmt komplette Blöcke mit Metadaten auf. Das Dateisystem Ext3 greift dabei auf das Journal Block Device (JBD) zurück [2]. Ein Dateisystem mit einem logischen Journal, wie XFS, ReiserFS 3 oder JFS, speichert Metadaten hingegen in einem eigenen, kompakteren Format.

Wird ein Journaling-Dateisystem nach einem abrupten Abbruch der Schreib-operationen erneut gemountet, versucht es, anhand der Informationen im Journal einen konsistenten Zustand herzustellen: Ist eine Transaktion wie das Anlegen einer Datei im Journal unvollständig, dann verwirft das Dateisystem sie. Ei-ne abgeschlossene Transaktion geht es Schritt für Schritt durch. Dabei prüft es, welche Änderungen schon auf dem Datenträger gelandet sind. Bislang ungeschriebene Änderungen holt es nun nach. Erst wenn alle Änderungen wirklich sicher auf dem Datenträger angekommen sind, markiert es die Transaktion als erledigt und gibt deren Speicherplatz im Journal wieder frei.

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Handwerk mit Format

    Formatierprogramme erledigen längst mehr als nur das Installieren von Dateisystemen. Wie gut sortierte Werkzeugkästen liefern sie für jede Aufgabe das richtige Helferlein. Wer die Performance steigern will, kitzelt über Mount-Optionen das letzte Stückchen Leistung aus Ext 3, JFS, ReiserFS oder XFS heraus.

  • Fsck

    Mit ihren Journalen müssten moderne Dateisysteme – so die reine Lehre – immun sein gegen Inkonsistenzen. Dass dem nicht so ist, zeigen die Allgegenwart von Fsck und ein Blick in die Filesystem-Historie.

  • Im roten Bereich

    Die Serverprodukte von Red Hat und Novell setzen verschiedene Dateisysteme ein. Dieser Artikel zeigt, inwieweit die Distributoren damit die richtige Wahl treffen und welche Alternativen es gibt.

  • Doppelte Buchführung

    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.

  • Need for Speed

    Wo sehr große Files und Dateisysteme vorkommen und gleichzeitig hohe Performance gefragt ist, müssen herkömmliche Dateisysteme passen. Einen Ausweg bietet Lustre, ein Performance-optimiertes verteiltes Dateisystem für Hochleistungsrechner.

comments powered by Disqus

Ausgabe 09/2014

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook