[sage-ka] fsck-Intervall bei ext3

[Andreas Jellinghaus]

Am Mittwoch 15 Juli 2009 15:31:38 schrieb Olaf Hopp:
> Vielen Dank fuer Eure Antworten, wenn
> auch meine eigentliche Frage nicht beantwortet wurde:
>
> ist es bei ext3 unbedingt sinnvoll/notwendig gelegentlich
> einen fsck zu machen.

fsck kann fehler in den meta daten zumindest teilweise erkennen.
wenn solche fehler existieren, ist es gut wenn man die möglichst
früh merkt. dafür ist fsck gut.

die frage ist eher, wie wahrscheinlich fehler in deinen meta-
daten sind? da muß man auf die ursachen schauen: fehler im
linux kernel/filesystem quellcode und hardware probleme
fallen mir vor allem ein. bug reports mit dem kernel als
ursache und der auswirkung: filesystem korruption - das liest
man sehr selten, selbst von leuten die bleeding-edge kernel
trees mit experimentellen features verwenden.

ich denke daher, das probleme am filesystem vor allem von
der hardware seite kommen können: hitze, ram-probleme, 
sonstige probleme an kontrollern, kabeln, leiterbahnen
etc. und natürlich defekte an festplatten.

gute hardware würde ich als erstes bevorzugen, um hardware
defekte zu minimieren. ecc-ram, nicht die super billig chipsätze,
saubere verkabelung, gut kühlung etc. dann eine gute überwachung:
cpu temperatur, rechner temperatur, lüftersteuerung, all sowas.
wenn man nicht merkt, das der rechner kurz vorm exitus steht,
werden auch fehler viel wahrscheinlicher.

ich würde daher vor allem auf software setzen, die mir kernel logs
überwacht, die smart werte kontrolliert, temperaturen überwacht
und all sowas. damit sollte auffallen, wenn am rechner was nicht
stimmt.

wenn es kein hardware defekt ist, bleibt noch eine weitere quelle:
stromausfall. ted tso hat dazu gute beispiele gebracht - der rechner
gibt dem chipsatz den befehl, daten zu schreiben. dann fällt der
strom aus. der chipsatz kann die daten noch übertragen und die platte
kann die daten noch schreiben. nur leider waren ram oder speicher kontroller
nicht lang genug mit strom versorgt, angekommen ist müll. gute alte
server hardware (sein beispiel waren sgi kisten, gilt bestimmt auch
für andere hersteller) hat einen interrupt für strom-ausfall, der
als erstes das I/O lahmlegt. lieber nichts mehr schreiben, als müll
der wohlmöglich das filesystem korrumpiert.

falls ein hardware experte anwesend ist, ich wäre an neuerungen zu
diesem thema sehr interessiert. bis dahin fürchte ich, das zumindest
normale chipsätze dieses problem haben, ob server chipsätze besser
sind, weis ich nicht.

mancher mag sagen, das gegen stromausfall eine usv hilft, das ist natürlich
richtig, wenn diese zuverlässiger ist, als der stromlieferant. ich habe
das gegenteil leider schon durchgemacht - usv ist mehrfach durchgebrannt,
ein server-netzteil soll schuld sein, der hersteller kann aber auch nicht
sagen welches. da danke, da war SWM zuverlässiger als die usv am ende.

hat das journal bei ext3 prüfsummen? ich kenn mich da nicht aus,
fürchte nicht. sonst wäre journaling evtl. ein weg um korruptionen
im filesystem durch stromausfälle zu verhindern. da könnte man auch
data journaling aktivieren, wenn die kiste weit weg von i/o last
ist (wenn man wenige daten schreibt mit kurzen peaks soll data journaling
ja schneller sein als kein journaling für daten - wäre also sogar
eine performance steigerung).

also kurz nochmal meine checkliste:
* vernüftige hardware?
* hardware überachung (smart, temperaturen, kernel log)?
* sich gedanken zu stromausfall gemacht und umgesetzt?

dann kann man fsck laufen lassen. einmal im monat reicht IMO,
wer mag auch gerne wöchentlich. bei der gelegenheit will ich dann
auch noch was wichtiges anmerken: prüft mal die daten eurer
RAIDs durch! (raid1/5/6) beim linux software raid kann man das
einfach in auftrag geben, reduziert natürlich die I/O performance
solange es läuft, aber hilft platten probleme aufzudecken.

ob oder wie man mit hardware raid kontrollern eine raid prüfung
in auftrag gibt und das ergebnis bekommt, das weis ich nicht. kann
jemand dazu was schreiben? ich bin da gebranntes kind, kenne vor
allem ein paar adaptec controller, deren linux tool unbrauchbar
war und im schlimmsten fall den kernel zum hängen brachte.

Tschüß, Andreas