[linux-l] fsck automatisieren

[Peter Ross]

Boris Kirkorowicz wrote:
> 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?

Jein. Zum einen haben moderne Filesysteme Features wie Journaling oder
aehnliches, die zu jedem Zeitpunkt ein konsistentes Filesystem
hinterlassen sollten. ext3 mit eingeschaltetem Journaling und reiserfs,
die beiden populaersten Linux-FS, gehoeren dazu.

Ein fsck ueber eine heimische 40-GB-Platte ist schon nervig, eine ueber
ein 360GB-RAID kann eine ganze Firma fuer ein Weilchen zum Kaffeetrinken
schicken. Daher will man das nicht unbedingt bei jedem Starten, egal, was
den Server dazu gebracht hat.

Allerdings kann ein modernes Filesystem damit auch selbst zum Problem
werden - ein fsck wird u.U. nie durchgefuehrt. Ich hatte mal ein
360GB-RAID, bei dem ich halt das "Solaris-UFS-Logging" eingeschaltet
hatte. Korruptes FS->Panic->Reboot->"Logging enabled. Skip
fsck"->Panic->Reboot (im 5 Minuten-Takt)

Bei ext3 gibt es einen Defaultwert, dass alle x Reboots oder y Tage
zwangsweise gecheckt wird, das haette unsere Sun nach ein paar Stunden
automatisch gerettet. Ich weiss nicht, wie sinnvoll das ist - ich habe
halt nach drei Reboots das Logging disabled, dem RAID einen ca.
1,5stuendigen fsck und der Firma eine lange Pause spendiert.

Und hier liegt ein Grund, kleinere Filesysteme, kleinere Partitionen, zu
verwenden.. Dabei ist es schon ganz huebsch, soetwas wie LVM und dynamisch
anpassbare Filesysteme zu haben, um dem "Verschnitt" statischer
Partitionierung zu entgehen.

Man will es nicht glauben, aber es gibt Dinge, fuer die sogenannte Admins
ganz sinnvoll sind;-)

Wie auch immer, ich halte nichts davon, Fehlerbehandlungen wie ein
modernes, aber kaputtes Filesystem zu automatisieren. Wenn es da hakt, ist
etwas wirklich faul und es bedarf der Untersuchung und Entscheidung eines
sogenannten Experten, um die Ursache zu beheben.

Hast Du ein Problem, gehe in Single-User-Mode und mache einen manuellen
fsck. Teste die Festplatte (dd if=/dev/$device of=/dev/null).

Tritt das Problem dann wieder auf, ist ein Bugreport faellig - und der
Gedanke des FS-Wechsels nicht abwegig.

Gruss
Peter