Journaling Filesysteme unter Linux

Ablauf beim Journaling

[ Seminar Linux und Apache ] ... [ Inhaltsübersicht ] ... [ Welche DS bieten Journaling ]

Übersicht

Was passiert ohne Journaling?

Hier interessieren im Wesentlichen die Geschehnisse nach einem Absturz bzw. einem "sauberen" Herunterfahren des Systems.
Im Superblock wird beim Mounten des Dateisystems ein sogenanntes Valid Bit gelöscht, das nach einem sauberen Unmount wieder gesetzt wird. Fehlt dieses Bit beim nächsten Start des Systems, bedeutet dies, dass das System nicht ordnungsgemäß heruntergefahren wurde. Jetzt wird ein Programm gestartet, e2fsck, das die Daten auf Konsistenz überprüft und wenn nötig zu reparieren versucht. Dies ist nicht immer erfolgreich. Dateien (oder Datenblöcke), die nicht ordnungsgemäß wiederhergestellt oder nicht richtig referenziert werden können, landen in einem extra dafür vorgesehenen /lost+found-Verzeichnis der Partition.
Da e2fsck über die gesamte Partition (oder Platte) laufen muss, kann diese Prozedur unter Umständen - je nach Größe des Dateisystems - einige Minuten kostbarer Uptime in Anspruch nehmen.

Wird eine Datei geändert, so wird beim Speichern zunächst einmal der geänderte Inhalt in den selben Block der Platte geschrieben wo die original Daten stehen. Danach wird der Inode mit den aktuellen Daten auf die Platte geschrieben.


 Update-Vorgang beim ext2fs [17]

Man kann sich leicht vorstellen was bei einem Stromausfall passiert. Bleibt der Rechner z.B. nach dem Schreiben des 2. Blockes stehen, so ist der neue Inhalt des Blockes 3 verloren, wobei der 2. Block eben schon diesen neuen Inhalt hat. Also nicht gerade das, was man sich wünscht.
Nun wird bei dem nächsten Booten ein FS-Check durchgeführt. Hierbei wird im Zweifelsfall nur eine eventuelle Inkonsistenz zwischen Inode und File gefunden. Dass die Datei nicht so vorliegt, wie gewünscht bleibt dabei vom FS-Check unbemerkt.

Nach oben

Wie funktioniert Journaling bzw. Logging?

Schreibende Zugriffe auf die Festplatte werden hier, wie bei Datenbanksystemen, in Transaktionen zusammengefasst. Eine Transaktion ist eine Menge von einzelnen Operationen, die bestimmte Eigenschaften haben. Die sogenannten ACID-Eigenschaften (Atomicity, Consistency, Isolation und Durability). Die in diesem Zusammenhang wichtigsten sind, dass die Operationen atomar (Atomicity) und abgegrenzt (Isolation) sind. Dies bedeutet, dass diese Operationen innnerhalb einer Transaktion fehlerfrei durchgeführt oder aber ohne Änderungen zu bewirken abgebrochen werden. Diese operationen können also auch nicht nur teilweise durchgeführt werden. Hier gilt dann "Alles" oder "Nichts".
In Datenbanksystemen werden diese Transaktionen im Log protokolliert. Es werden aber nicht nur die Namen der Operationen in dieses Log geschrieben, sondern auch die Inhalte, die durch diese Operationen geändert werden.
In Journaling Filesystemen werden nur die Metadaten wie z.B. Inodes, Inode-Maps und ähnliches protokolliert.

Als Beispiel für den Ablauf soll hier der beim XFS beschrieben werden:
1. Transaktion erstellen Als erstes wird eine neue Transaktion mit einer eindeutigen Transaktions-ID erstellt.
2. Log-Speicher reservieren Ist die Transaktion erstelt muss für diese Transaktion Speicher im Log reserviert werden, um sicherzustellen, dass das Ende des Log nicht überschritten wird. Da jede Transaktion vor Beginn sicherstellt dass genugt Speicher im Log vorhanden ist, werden Deadlocks vermieden. Würde eine Transaktion den Rahmen des Logs sprengen, so könnten keine Daten mehr ins Log geschrieben werden, allerdings kann auch kein Speicher freigegeben werde, da die Transaktion noch nicht abgeschlossen wurde.
Ist für eine Transaktion kein ausreichender Speicherplatz verfügbar, so wird diese schlafend gelegt, bis der Speicher frei ist.
Der Speicher wird wieder freigegeben sobald die Transaktion komplett ausgeführt wurde.
3. Resourcen reservieren Dieser Schritt vermischt sich etwas mit dem nächsten. Hier werden das Lesen und Blockieren (lock) der zu ändernden Resourcen durchgeführt. hierbei ist zu bemerken, dass keine inerhalb einer Transaktion blockierte Resource freigegeben (unlock) werden kann, solange nicht alle benötigten Resourcen blockiert wurden. Eine Reihenfolge wie ..., lock A, unlock A, lock B, ... ist also nicht zulässig.
4. Bearbeiten der Resource Wenn eine Resource blockiert ist kann sie bearbeitet werden. Im Log weden die Teile der Resource, die geändert werden, protokoliiert.
5. Commit Transaktion Sind alle Änderungen durchgeführt, kann die Transaktion abgeschlossen werden. Alle Änderungen und die entsprechenden Operationen werden in das Log geschrieben. Da dieses Log (in-core log) sich im Hauptspeicher befindet sind diese Änderungen noch nicht permanent. Dies ist erst dann der Fall, wenn dieses Log auf die Platte geschrieben wird.
Da es längere Aktionen gibt, die auf mehrere Transaktionen aufgeteilt werden, kann bestimmt werden, ob die Resourcen nach dem Commit einer Transaktion wieder freigegeben werden, oder ob sie für die nächste Transaktion weiter reserviert bleiben soll.
6. Log-Inhalt speichern In gewissen Abständen wird das in-core-Log auf die Platte geschrieben. An dieser Stelle wird dann eine Transaktion permanent. Die Transaktion wird erst danach wieder gelöscht und ist somit komplett abgearbeitet.
Die geänderten Resourcen werden in einer Liste, der Active Items List (AIL) vermerkt. Hierdurch wird festgehalten, dass die resource geändert wurde, und dass sich der neue Inhalt im Log auf der Platte befindet.
7. Inhalt auf Platte schreiben Zum Schluss wird der geänderte Inhalt an die entsprechende Stelle auf der Platte zurückgeschrieben. Die Resource wird aus der AIL gelöscht.



 Update-Vorgang beim Journaling Filesystem [17]


Nach oben
[ Seminar Linux und Apache ] ... [ Inhaltsübersicht ] ... [ Welche DS bieten Journaling ]