[linux-l] fsck automatisieren

Frank Reker frank at reker.net
Di Apr 20 00:22:11 CEST 2004


Boris Kirkorowicz disse:
> Hallo,
>
> Am 19.04.04 19.30 schrieb Frank Reker:
>> Eine Kernel Panic deutet meist auf einen Bug im Kernel hin.
>> Wenn der Fehler natuerlich im Filesystemtreiber (oder einer der
>> darunter liegenden Ebenen) auftrat, dann ist ein fs-check
>> empfehlenswert, ansonsten nicht.
>
> 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.




-- 
Don't worry be happy ...
Ciao Frank



Mehr Informationen über die Mailingliste linux-l