[linux-l] fsck automatisieren

[Dani Oderbolz]

Frank Reker wrote:

> Boris Kirkorowicz disse:
>>
>>Zu meinem Verständnis: ist es nicht weitgehend egal, aus welchem Grund das
>>Dateisystem unsauber ist? In jedem Fall deutet es doch darauf hin, daß ein
>>Schreibvorgang nicht abgeschlossen wurde, und da kann doch immer
>>Datensalat
>>zurückgeblieben sein?
> 
> 
> Bei journaled fs wie ext3 oder reiserfs, etc. werden zumindest die Metadaten
> (bein ext3 kann man auch die benutzerdaten journaln) zuerst in ein journal
> geschrieben, und dann erst ins eigentliche fs. Dadurch kann ein
> Schreibvorgang entweder rueckgaengig oder vollendet werden, je nachdem
> an welchem Punkt die unterbrechung war. Dadurch ist gewaehrleistet,
> dass das fs immer konsistent ist, da entweder alles geschrieben wurde,
> oder gar nichts. Lediglich die Information innerhalb der Datei kann
> inkonsistent sein. Wenn bei ext3 auch benutzerdaten gejournalt werden,
> ist auch die Konsistenz innerhalb einer Datei gewaehrleistet, sprich:
> enweder stehen da die Daten von vor dem Schreibvorgang oder die
> geschriebenen. Soetwas kostet natuerlich performance, sodass es haeufig
> deaktiviert wird, und nur metadaten gejournalt werden. In jedem Fall
> macht dieser Vorgang ein fs-check ueberfluessig, da das fs nicht
> inkonsistent werden kann.
> Sollte allerdings ein Fehler im fs-treiber vorhanden sein, ist die
> Konsistenz verstaendlicherweise nicht mehr gewaehrleistet.

So weit die Theorie.
Selbst bei Datenbanken (deren Aufgabe ja gerade dieses ist: Erhalt der Konsistenz),
ist es absolout vernünftig, ab und zu einen Konsistenzcheck zu machen.
Stichworte: Hardwarefehler, Softwarefehler (soll ja schon vorgekommen sein).
Ich finde es nicht gut, dass sich diese Meinung:
Journaling = kein fsck so durchsetzt.
Es ist sicher richtig, dass man nicht mehr so oft einen fsck machen muss,
aber auch ein journaling FS ist vor Problemen nicht gefeit.

Gruss,
Dani


-- 
Daniel Oderbolz
Jagowstrasse 13
D-10555 Berlin
http://www.oderbolz.org