✎ computer:journaling-dateisystem [/var]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
Ein Journaling-Dateisystem unterscheidet sich im Bezug auf die Funktion bei Fehlerfällen enorm von herkömmlichen Dateisystemen.


======Defintion und Nutzen======

Ein Journaling-Dateisystem definiert sich dadurch, dass es Änderungen vor dem eigentlichen Speichern in einem Speicherbereich zwischenpeichert – dem Journal.
Das hat den Vorteil und Nutzen, dass Daten und Datenzustände im Fehlerfall rekonstruiert werden können. Somit kann man Datenverlust entgegenwirken. Im Vergleich zu einem herkömmlichen Dateisystem kann ein Journaling-Dateisystem im Fehlerfall auch mit höherer Wahrscheinlichkeit wiederhergestellt werden.
Ferner durchlaufen Dateisystem Konsistenz-Tests bei Journaling-Dateisystemen wesentlich scheller als bei herkömmlichen Dateisystemen. Das hat damit zu tun, dass beim herkömmliche Dateisystem kein Journal vorhanden ist und das Dateisystem auf komplizierte Art und Weise wieder in einen konsistenten Zustand gebracht werden muss.
Es gibt zwei Typen des Journals – das Metadaten- und das Full-Journaling. Das Metadaten-Journaling sichert lediglich die Konsistenz des Dateisystems, dazu gehören Datei-Informationen, wie z.B. die Angabe der Datenblöcke einer Datei und deren Besitzer und Gruppe. Ohne diese Informationen ist eine Datei nicht verwendbar und wird auch als "//Dateileiche//" bezeichnet. Beim Full-Journaling können neben den Metadaten auch Datei-Inhalte rekonstruiert werden. 


======Musterbeispiel - Vorteil von Journaling======

Verdeutlichen wir das Thema an einem anschaulichen Beispiel. Nehmen wir an, ein Benutzer verfügt über 2 Rechner mit 2 unterschiedlichen Betriebs- und Dateisystem – auf Computer 1 ist Microsoft Windows 98 installiert, auf dem zweiten wird ArchLinux verendet. Da es sich bei Microsoft Windows 98 um ein älteres Betriebsystem handelt, wird dort noch FAT32 verwendet – FAT32 ist ein non-journaling Dateisystem, da es über kein Journal verfügt. Auf dem Linux-Rechner hingegen wird das Dateisystem reiserFS benutzt, welches Journaling unterstützt.
Beide Rechner kopieren eine Spiegelabbilddatei wichtiger Firmendaten, als plötzlich der Strom ausfällt und die beiden Rechner ausfallen.

=====Folgen des Beispiels und der erste Bootvorgang=====

Was sind potenzielle Folgen auf beiden Rechnern?

Beide Dateisysteme sind inkonsistent, da mitten in einer nicht abgeschlossenen Schreiboperation der Rechner ausfiel. Während bei der FAT32-Festplatte die Daten nicht rekonstruiert werden können, wird beim reiserFS-Dateisystem das Dateisystem überprüft und anschließend mit dem Journal abgeglichen (//später dazu mehr!//). Verlorene Dateien sind beim FAT32-System verschwunden – das reiserFS-Dateisystem kann nicht nur das Dateisystem, sondern auch Dateien rekonstruieren (sogenanntes Full-Journaling).
Die Zerstörung des Dateisystems und der Dateien ist beim Linux-Rechner eher unwahrscheinlich, während die Zerstörung des FAT32-Dateisystems aufgrund des mangelnden Dateisystems und der schlechten Wiederherstellungsmöglichkeiten eher erdenklich ist. 

Eine Anmerkung zu den nächsten Beiden Szenrarien - hierbei handelt es sich lediglich um theoretische Folgen. In der Realität müssen diese Effekte nicht unbedingt eintreten.

====Windows-Rechner mit FAT32====

  * System wird gestartet
  * Die Dateisystem-Inkonsistenz wird erkannt und behoben
  * Daten sind wahrscheinlich verloren – eine eventuelle Rettung mit Software eines Drittanbieters ist allerdings in einigen Fällen noch möglich

====Linux-Rechner====

  * Nach dem Laden des Kernels wird das System gestartet
  * Das fehlerhafte Dateisystem wird erkannt und das Journal wird „befragt“
  * Sind noch Daten im Journal?
  * Wurden die Daten schon auf der Festplatte gesichert?
  * Sind diese Daten gültig (//commit-Flag, Prüfsumme//)?

Nur wenn die Daten noch nicht gesichert wurden und gültig sind, werden sie auf der Festplatte gesichert.

=====Probleme bei Dateisystemen=====

Um den Zusammenhang und die Problematik von non-Journaling Dateisystemen zu verstehen, ist es notwendig, das Prinzip von Dateisystemen zu verstehen.

Dateisysteme speichern Informationen über Dateien, Verzeichnisse und weitere Dateisystem-abhängige Strukturen. Dateien liegen in unterschiedlichen Bereichen auf der Festplatte vor, weshalb bei Veränderungen (//z.B. einer Ordner-Verschiebung//) Operationen an mehreren Stellen der Festplatte erfolgen müssen.
Nehmen wir als Beispiel an, ein Benutzer möchte Ordner A nach Ordner B verschieben, in dem allerdings auch weitere Ordner liegen. Das sind mehrere Schreiboperationen:

  * Entferne Ordner A aus XYZ
  * Füge Ordner A in 123 ein

Bevor diese zwei Schreiboperationen nicht abgeschlossen sind, ist das Dateisystem //inkonsistent//, da es verändert wurde. Vor den beiden Schreibzugriffen und danach gilt es wieder als //konsistent//.


=====Journal-Funktionsweise=====

Wie bereits erwähnt, werden Änderungen vor dem eigentlichen Speichern in einem Speicherbereich, dem Journal gespeichert. In bestimmten Zeitabständen wird das Journal auf die Festplatte gespeichert und danach geleert, sodass neue Datei-Änderungen in ihm gespeichert werden können. Der Zeitabstand, in dem dieser Vorgang stattfindet, variiert je nach Dateisystem. Bei vielen Dateisystemen lässt sich dieser Intervall allerdings auch manuell festlegen. So kann, je nach Verwendungszweck, die Datensicherheit maximiert werden, indem der Intervall veringert wird. Nicht verachtet sollte werden, dass, linear zur Verkürzung des Intervalls auch die Zugriffslast auf die Festplatte erhöht wird. Insbesondere bei Speichermedien mit beschränkter Lebenszeit, wie z.B. SSDs oder Speicherkarten ist **dringend** von der Benutzung von Journaling-Dateisystemen abzuraten!
Die richtigen Datei-Inhalte und Speicherungen werden durch Prüfsummen sichergestellt.
Wird das Dateisystem nicht korrekt ausgehängt, z.B. weil der Rechner abgestürzt ist, wird der Inhalt des Journals mit dem auf der Festplatte verglichen, falls die Daten im Journal gültig sind. In so einem Fall ist das so genannte **commit-Flag** gesetzt.


====Nachteil====

So gut durchdacht und praktisch Journaling-Dateisysteme auch sind, sie schützen nicht vor dem //worst case//. Nehmen wir einmal an, der Rechner stürzt genau in dem Moment ab, in dem die Dateiänderungen in das Journal geschrieben werden sollen. Das Journal ist in dem Fall noch nicht beschrieben, auf der Festplatte sind die Änderungen ohnehin noch lange nicht vorhanden. Stürzt der Rechner genau hier ab, ist selbst das Journaling-Dateisystem wirkungslos. Es sind keine Informationen, nicht einmal Fragmente, vorhanden, die abgeglichen werden könnten. Pech gehabt.
Es gibt also keine vollkommen sichere Garantie, dass die Daten im Fehlerfall erhalten bleiben. Außerdem wird die CPU mehr belastet, als bei herkömmlichen Dateisystem. Das sollte die Performance des Betriebssystems allerdings sowie auf aktuellen als auch auf älteren Rechnern nicht negativ beeinflussen. Die häufigeren IO-Zugriffe auf das Speichermedium stellen allerdings ein ernstzunehmendes Problem dar. Insbesondere bei Speicherkarten und den häufig in den trendigen Netbooks verbauten SSDs sollten keine Journaling-Dateisysteme verwendet werden, um eine lange Lebenszeit der SSD zu ermöglichen.

====Beispiele====

===Full-Journaling===

  * ext3
  * ext4
  * reiserFS

====Metadaten-Journaling====

  * NTFS
  * XFS
  * JFS

======Quellen======
http://glossar.hs-augsburg.de/Journaling-Dateisystem
Benutzer-Werkzeuge

Webseiten-Werkzeuge

Seiten-Werkzeuge
