Hallo, Am Dienstag, 21. August 2007 16:22 schrieb Lentes, Bernd:
Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt.
Nach einem schlimmen Crash tun das auch andere Dateisysteme. Es ist eher die Frage, wie anfällig Journalling-Systeme für so heftige Defekte sind, daß das Journalling auch nichts mehr bringt.
Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Dauert schon bei einigen zehn GB nach meiner Erfahrung ziemlich lange, aber natürlich hängt das sowohl von der Geschwindigkeit der Platte als auch von der Anzahl der Defekte im Dateisystem ab. Andere Parameter mögen dafür auch eine Rolle spielen. Aber die Korrektheit der Reparatur geht für mich vor. Die Reparaturdauer ist Nebensache, denn allzu oft wird es ja wohl nicht passieren. Sonst wäre das Dateisystem nicht so stabil, wie ich mir das wünsche. Mit reiserfs habe ich keine Reparaturerfahrung, da ich damit noch nie einen Crash (z.B. auf einem kleinen Mail-Server) hatte. Allerdings hatte ich mal beim Einrichten von reiserfs einige Ungereimtheiten, so daß ich gleich wieder die Finger davon ließ (obwohl ich es schon mit Erfolg benutzte).
Ich gehe davon aus, daß jedes vernünftige Dateisystem nach einem Crash einen Check durchführt. Das ist ja auch gut so.
Ich dachte bis vor kurzem immer, daß durch das Journalling auch bei einem Stromausfall noch nicht abgeschlossene Schreibvorgänge protokolliert werden und somit nach einem Wiederhochfahren des Systems entweder fertiggestellt oder bei Mangel an genügenden Infos über den Schreibvorgang gar nicht mehr getätigt werden, so daß am Ende keine im technischen Sinne fehlerhaften Dateien übrigbleiben. Es können natürlich der einen oder anderen Datei dann Informationen fehlen, die man schon für geschrieben hielt. Aber technisch sollten sie in Ordnung sein. Durch das Journalling sollten m.a.W. die Schreibvorgänge atomar (unteilbar) werden, also entweder ganz oder gar nicht auf dem Dateisystem durchgeführt werden - zumindest war das bisher immer meine Vorstellung. Bisher, denn im letzten halben Jahr hatte ich zwei heftige Defekte auf mehreren ext3-Dateisystemen auf zwei Platten, und zwar nicht aufgrund eines Stromausfalls, sondern kürzlich einmal mitten im normalen Betrieb (cups druckte nicht mehr richtig und Firefox ließ sich nicht mehr starten und einige andere seltsame, aber harmlose Anomalien) und das andere Mal war vor 6 Monaten, nach einem gezielten Reboot. Beim Hochfahren waren die ext3-Systeme derart defekt, daß eine automatische Reparatur durch fsck.ext3 nicht mehr möglich war. Das Journalling von ext3 scheint nicht so das Gelbe vom Ei zu sein. Es ist wohl auch nicht so fest mit dem eigentlichen Dateisystem wie z.B. bei reiserfs verbunden, sondern scheint eher ein Aufsatz auf ext2 zu sein. Ob das ein Nachteil sein muß, weiß ich nicht. Freilich habe ich mit meinen zwei Ausfällen keine gute statistische Signifikanz - da kann auch mal viel Pech im Spiel sein. Nach der Reparatur jeweils mit fsck.ext3 -cvy /dev/hda<x> waren auf den Systemen unter /usr und /opt etliche Software-Pakete defekt aber auch auf anderen Systemen fehlten jeden Menge Daten, die jedoch alle wieder installiert bzw. wiederhergestellt werden konnten. Auffällig war, daß in beiden Fällen die Uptime > 150 Tage war, aber ich dachte, das sei für Unix-Systeme nichts besonderes. Ich hatte übrigens keine Bad Blocks auf den Platten. Ich erwähne das nur, weil natürlich Journalling dagegen auch nichts machen kann, wenn welche während des Betriebs auftreten.
Und das sollte bei jounailling-Dateisystemen wie reiserfs und ext3 eigentlich recht flott gehen.
Genauer gesagt, ist es ja der Sinn von Journalling, daß nach einem Stromausfall oder allgemein nach einem "Nichtabschließenkönnen" von Schreibvorgängen Reparaturen mit fsck am Dateisystem unnötig sind, weil das System sozusagen "clean" bleibt, denn ein Schreibvorgang ins Dateisystem wird solange nicht aus dem Journal ausgetragen, bis er vollständig im Dateisystem abgeschlossen ist. Bei einem unvollständigen Schreibvorgang muß der ursprüngliche Zustand einer Datei aus dem Journal rekonstruiert werden können, so das eben keine Reparatur mit fsck nötig ist. Welche Vorgänge bei mir passierten, daß das Journalling nichts mehr half, weiß ich nicht. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org