[sage-ka] fsck-Intervall bei ext3

[marco hemminger]

-------- Original-Nachricht --------
> Datum: Thu, 16 Jul 2009 20:39:48 +0200
> Von: Andreas Jellinghaus <aj at dungeon.inka.de>
> An: sage-ka at guug.de
> Betreff: Re: [sage-ka] fsck-Intervall bei ext3



> 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?

Oder vielleicht doch ein anderes FS *duck

> 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.

Raid-Kontroller sind immer etwas Glückssache. Ich hatte schon RAID-Kontroller von unterschiedlichen Herstellern in den Fingern (Adaptec, ICP, LSI). Manche laufen out of the box mit Kernel-Treibern und geben ihren Status über ein /proc-Device bekannt. Bei manchen Distributionen sind zum Teil sogar noch zusätzliche Tools mit dabei zur Überwachung. Wenn man Pech hat, muss man aber extra Tools installieren, die mit etwas Pech nicht funktionieren und nur den Rechner aufhängen. Diese Erfahrung musste ich leider auch schon machen. Genauso die Erfahrung, das manche Raid-Kontroller unter Linux überhaupt keine Möglichkeit bieten den Raid-Status auszulesen. Dann sieht man nur wenn eine Platte kaputt ist, wenn man sieht das die Platte blinkt. So etwas ist schwer mitzubekommen wenn man die Server nicht im Büro stehen hat, sondern irgendwo bei einem Housing-Anbieter. 

Noch eine Spur schwieriger ist es Tools zu bekommen, mit denen man im laufenden Betrieb ein Rebuild des Raids anstossen kann ohne das den Rechner neu booten zu müssen und in die Firmware zu wechseln.

Die richtige Strategie wäre hier wohl einfach Kontroller zu kaufen, die problemlos unter Linux laufen, am besten mit Kernel-Treiber und wo sich der Status standardmässig über ein /proc-Device auslesen lässt. Wenn es dann noch weitere Tools gibt, die problemlos laufen und die eventuell gängigen Distributionen schon beiligen, dann hat man wohl den perfekten Kontroller gefunden:)

Leider bieten die meisten Lieferanten nur 1-2 verschiedene Kontrollermodelle als Option für Ihre Server an. Und ob ein bestimmter Kontroller wirklich problemlos funktioniert, findet man meist erst hinterher raus. Hab mir da leider auch schon die Finger damit verbrannt (Stichwort Firmwareunterstütztes Software-Raid bei onboard-SATA Chipsätzen). Oder gibt es bei Kontrollern da irgend ein Geheimtip?

Eine weitere Alternative ist natürlich von vorne herein auf Software-Raid zu setzen. Hab gehört das manche Admins prinzipiell Software-Raid verwenden. Man hört da immer irgendwelche Horrorstories von gestorbenen Kontrollern, für die sich kein Ersatz mehr beschaffen lässt und wo ein neueres Modell das bereits angelegte Raid auf den Platten nicht mehr erkennt.



Gruß,

Marco
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01