Die Problematik ist eigentlich schon lange bekannt. Ein hardwaremässiger Write-Back-Cache ist prinzipiell schon mal ein Sicherheitsrisiko. In Verbindung mit RAID und/oder Journalling ist es schon fast fahrlässig, den Cache eingeschaltet zu lassen, denn dort muss das Betriebssystem bzw. der RAID-Kontroller jederzeit wissen, welche Daten physikalisch tatsächlich geschrieben wurden.

Und übrigens, um es nochmals zu betonen: Journalling erhöht das Risiko von Datenkorruption. Es ist ein Bequemlichkeitsfeature (schnellerer fsck), nicht ein Sicherheitsfeature.

Nein. Ein Journal schränkt lediglich ein, wo die Daten korrumpiert sein könnten. Das heisst: Beim Reboot nach einem Absturz weiss das Betriebssystem gleich, wo Fehler sein könnten, und muss nicht die gesamte Festplatte untersuchen. Ansonsten bringt ein Journal nichts. Schäden an den Daten können nur durch ein stabiles Design des Dateisystems verhindert oder eingeschränkt werden.

Also, nochmals ganz langsam:

0. Wenn Du bei Schreibzugriffen gar keine Daten verlieren willst, darfst Du gar keine Write-Caches halten. Weder auf Festplatte, noch im RAM. Das hat nicht mal Unix V6 geschafft, weil sogar da ein Sektor im RAM zwischengespeichert wurde.

1. Ansonsten:

1a. Du kannst synchron mounten. Laeuft immer noch Gefahr Daten zu verlieren, falls man im falschen Moment abstellt, da Write-Cache vorhanden.

1b. Falls Du die Schaeden lokalisieren willst, brauchst Du einen Log-Mechanismus, also einen Mechanismus, wo Du die Reihenfolge der Schreibzugriffe eruieren kannst und Rollbacks durchfuehren zu koennen. -> Journalling-Filesystem.

1c. Alternative zu 1a: Soft-Updates

2b. Wo der Log liegt ist Dir freigestellt. Das muss nicht auf der Platte sein, es kann auch ein NVRAM sein.

War das klar genug?

Ach ja:

- Nicht nur das File System muss mitspielen, auch das Virtual Memory Subsystem und die Harddisk-Komponenten (zu Punkt 0).

- Kein Log: kann Dir das gesamte Filesystem crashen.

0: Stimmt. Es wäre aber noch anzufügen, das ein Hardware Write-Back-Cache ein wesentlich grösseres Risiko darstellt, weil niemand ausser der Steuerelektronik der Harddisk die Kontrolle darüber hat.

1b: Das ist falsch. Das Journal hilft zwar bei der Fehlersuche, aber es ist nicht Voraussetzung.

Ein Log kann nur helfen, Veränderungen an der Dateisystemstruktur rückgängig zu machen. Solche sollten ein Dateisystem nicht aus dem Tritt bringen. Sogar bei FAT lässt sich sowas reparieren. Kritisch wird es immer dann, wenn wichtige Dateisysteminformationen beschädigt werden (Superblock etc.). Die kann ein Journal nicht retten. Es ist vielmehr ein Teil davon.

Fazit: Journaling vereinfacht die Fehlersuche und -korrektur. Prinzipiell wird die Sicherheit aber nicht erhöht, denn beides muss auch ohne Journal möglich sein. Ist die Fehlerbehebung ohne Journal nicht möglich, so stellt das Journal einen SPF dar. Ein solches Dateisystem ist extrem unsicher.

Ein Log kann nur helfen, Veränderungen an der Dateisystemstruktur rückgängig zu machen. Solche sollten ein Dateisystem nicht aus dem Tritt bringen.

Sogar bei FAT lässt sich sowas reparieren.

Kritisch wird es immer dann, wenn wichtige Dateisysteminformationen beschädigt werden (Superblock etc.).

Die kann ein Journal nicht retten.

Es ist vielmehr ein Teil davon.

Okay, die Aufteilung der Metadaten in Strukturdaten und Informationen war ungenau, und für unseren Fall eigentlich irrelevant. Vergiss sie.

Worauf ich hinaus will, zeige ich am besten anhand eines Zitates: "Die Veraenderungen im Filesystem kannst Du nicht rueckgaengig machen, wenn Du die Reihenfolge nicht kennst." Wenn du damit meinst, dass der exakte Zustand der Metadaten beim letzten Syncpoint vor Absturz nur mittels eines Logs garantiert wiederhergestellt werden kann, dann stimme ich dir zu. Aber: Es muss immer möglich sein, diesen Zustand auch ohne Log mittels eines klassischen fsck wiederherzustellen. Ansonsten ist das Dateisystem futsch, wenn das Log fehlt. Genau das war ja lange ein grosser Kritikpunkt an ReiserFS.

Ich habe mir das ganze mal etwas durch den Kopf gehen lassen, und habe beschlossen, mein Statement etwas zu entschärfen. Statt "Journalling erhöht die Sicherheit nicht" sage ich jetzt "Journalling erhöht die Sicherheit nur wenig." ;-) Dabei bleibe ich aber, denn erfahrungsgemäss sind in der Praxis Fehler, die von einem fsck nicht behoben werden können, auch durch ein Journal nicht zu beheben.

Hmmm, was ziehen wir jetzt für ein Fazit? Ach ja: Journaling entbindet nicht von der Pflicht zum Backup.

PS: FAT ist eigentlich noch erstaunlich stabil. Aber mit aktuellen Dateisystemen kann es nicht mithalten, dass ist klar.

Wenn du damit meinst, dass der exakte Zustand der Metadaten beim letzten Syncpoint vor Absturz nur mittels eines Logs garantiert wiederhergestellt werden kann, dann stimme ich dir zu.

Aber: Es muss immer möglich sein, diesen Zustand auch ohne Log mittels eines klassischen fsck wiederherzustellen.

Ansonsten ist das Dateisystem futsch, wenn das Log fehlt.

Genau das war ja lange ein grosser Kritikpunkt an ReiserFS.

denn erfahrungsgemäss sind in der Praxis Fehler, die von einem fsck nicht behoben werden können, auch durch ein Journal nicht zu beheben.

Dies sind die wirklich groben Fehler (Konsistenz des Filesystems im Eimer). Ein Journal kann dies hoechstens zu verhindern versuchen, aber wenn fsck unkorrigierbare Fehler findet, ist es definitiv zu spaet.

Hmmm, was ziehen wir jetzt für ein Fazit? Ach ja: Journaling entbindet nicht von der Pflicht zum Backup.

PS: FAT ist eigentlich noch erstaunlich stabil.