Am Wed, 17 Mar 2010 18:58:21 +0100 schrieb Thomas Michalka :

Hallo Dieter,

Dieter Kluenter schrieb:

...

Thomas Michalka writes:

...

Hallo allerseits,

innerhalb weniger Tage hatte ich auf verschiedenen Systemen Ärger mit den genannten Dateisystemen, nur in einem Fall nach einem kurzen Stromausfall, letzteres trotz Journalling. Alle aber waren mehrere Monate am Laufen. Die Reparaturen hatten jeweils sehr vielen Dateien und Verzeichnisse in lost+found zur Folge

Dateien in lost+found deuten auf einen Plattendefekt hin.

Kann ich so nicht bestätigen, denn smartctl liefert bei allen Platten Werte im grünen Bereich in der Statistik über die Vergangenheit der Platten (s.u.). Wäre auch seltsam, denn ich hatte besonders bei einer IDE-Platte, die älter als 6 Jahre ist, schon mindestens zweimal Dateien in einigen lost+found-Verzeichnissen nach dem normalen Herunterfahren, aber das System ist mit der Platte während des Laufs absolut störungsfrei. @ Martin: smartd läuft und hat im Syslog niemals alarmiert.

Gut, dann haben wir gegenteilige Erfahrungen.

...

...

Bei anderen Systemen mit häufigeren Shutdowns/Reboots habe ich noch nie Dateisystemfehler beobachtet. Werden Dateisysteme mit zunehmender Uptime generell inkonsistenter? Wenn ja, woran liegt das -- unzuverlässiger Dateisystem-Code, äussere Einflüsse? Gibt es darüber Untersuchungen?

Eigentlich ist es umgekehrt, häufiges Reboot führt zu Inkonsitenzen und Plattendefekten, daher sind lange uptime Perioden wünschenswert,

Dem widersprechen leider meine Erfahrungen ganz eindeutig. Anders herum wär's mir auch lieber ...

Jeder Bootprozess verkürzt die Lebensdauer einer Platte.

...

...

Was setzt Ihr für Dateisysteme auf lang laufenden Servern ein? Oder lasst Ihr sie nicht über Monate durchlaufen? Was denkt Ihr über ext4? Ist ja noch nicht so lang im Praxistest.

Naja, ext2 gibt es seit nahezu 20 Jahren, ext3 und ext4 sind im Prinzip ext2 mit zusätzlichen Journaling-Funktionen. [...]

...

...

Ist es sinnvoll, regelmäßig mit init 1 in den Single-User-Mode zu gehen und nach dem Unmounten aller Dateisysteme ausser / diese mit 'e2fsck [-p|-y|-n] /dev/sd<x>' bzw. den entsprechenden Reiser-Tools zu prüfen und ggf. zu reparieren? Auch das Root-FS kann man meines Wissens prüfen, wenn es vorher mit mount -o remount,ro neu gemountet wurde.

Nein, bitte nicht.

Warum nicht?

Weil dadurch den Lebenszyklus der Platte erheblich verkürzt wird. [...]

Dass hier die Link-Geschwindigkeit auf 1,5 GBit/s heruntergesetzt wird, scheint an einem ATA-Bus-Fehler zu liegen. Allerdings war das trotz desselben Fehlers kurz davor nicht der Fall.

Hängen da noch andere Geräte dran? Z.B. CDROM, DVD, Multikartenleser oder ähnliches?

Müsste der Syslog von solchen Meldungen bzgl. der Platten und ATA völlig frei sein?

Das hängt vom Loglevel ab, aber es macht Sinn, das Warnungen und Errors an Syslog gegeben werden. [...] -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:8EF7B6C6 53°37'09,95"N 10°08'02,42"E -- 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

Hallo zusammen, Martin Hofius schrieb:

Hallo,

Am Mittwoch, 17. März 2010 schrieb Dieter Kluenter:

...

Am Wed, 17 Mar 2010 18:58:21 +0100

schrieb Thomas Michalka :

...

Hallo Dieter,

Dieter Kluenter schrieb:

...

Thomas Michalka writes:

...

Hallo allerseits,

innerhalb weniger Tage hatte ich auf verschiedenen Systemen Ärger mit den genannten Dateisystemen, nur in einem Fall nach einem kurzen Stromausfall, letzteres trotz Journalling. Alle aber waren mehrere Monate am Laufen. Die Reparaturen hatten jeweils sehr vielen Dateien und Verzeichnisse in lost+found zur Folge Dateien in lost+found deuten auf einen Plattendefekt hin. Einspruch... dort finden sich doch wohl eher Daten, die aufgrund einer defekten Dateisystemstruktur nicht mehr zugeordnet werden können. Das kann auch theoretisch durch Plattendefekte verursacht werden, muß aber nicht.

Tatsächlich wurde einiges an der Dateisystemstruktur repariert ... jede Menge orphaned inodes u.s.w., daher auch die Dateien in lost+found

...

...

...

Eigentlich ist es umgekehrt, häufiges Reboot führt zu Inkonsitenzen und Plattendefekten, daher sind lange uptime Perioden wünschenswert, Dem widersprechen leider meine Erfahrungen ganz eindeutig. Anders herum wär's mir auch lieber ... Jeder Bootprozess verkürzt die Lebensdauer einer Platte. wieso sollte das so sein? Siehe unten... ...

Vielleicht dann, wenn das System auch ausgeschaltet wird, denn dann wird der Plattenstapel beim erneuten Start beschleunigt. Ausserdem hat man in dem Fall natürlich eine etwas größere Temperaturschwankung, als im Dauerbetrieb. Die Platte muss erst wieder von Raumtemperatur auf normale Betriebstemperatur kommen. Möglicherweise muss die Positionierung der Servomotoren neu kalibriert werden.

...

...

...

...

Ist es sinnvoll, regelmäßig mit init 1 in den Single-User-Mode zu gehen und nach dem Unmounten aller Dateisysteme ausser / diese mit 'e2fsck [-p|-y|-n] /dev/sd<x>' bzw. den entsprechenden Reiser-Tools zu prüfen und ggf. zu reparieren? Auch das Root-FS kann man meines Wissens prüfen, wenn es vorher mit mount -o remount,ro neu gemountet wurde. Nein, bitte nicht. Warum nicht? Weil dadurch den Lebenszyklus der Platte erheblich verkürzt wird. Wenn ich das richtig sehe, geht es um SATA-Platten.

Richtig, aber auch um eine P-ATA/IDE-Platte, die sich aber von S-ATA-Platten wohl nur durch das Interface parallel/seriell und die dazugehörige Elektronik und vielleicht noch durch diverse ATA-Kommandos unterscheidet, nicht aber so gewaltig in der Plattenmechanik und der Art der Aufzeichnung der Daten. Deshalb musste wohl der Dateisystem-Code nicht groß für S-ATA-Platten angepasst werden.

Die sollten von der Auslegung sowieso eher für einen typischen Bürobetrieb gut sein, also einige Stunden Laufzeit und zwischendurch ausgeschaltet (bei echten Serverplatten stimme ich Dir zu, dass ein Ausschalten der Platten sehr an der Lebensdauer zehrt).

Angeblich mögen es IDE/ATA-Platten nicht besonders, wenn sie dauernd laufen. Ich habe aber auch schon vor längerem in der c't gelesen, dass das schon lange der Vergangenheit angehört. Inzwischen sind die MTBFs derart hoch, dass man davon ausgehen muss, dass auch eine ATA/IDE-Platte in einem kleinen Server mit nicht übermässiger Auslastung nur noch sehr selten kaputtgeht. Hat man viele Platten, vervielfacht sich gegenüber einer natürlich entsprechend die Wahrscheinlichkeit, dass innerhalb eines bestimmten Zeitraums eine davon das Zeitliche segnet. Ich hatte übrigens während meiner gesamten 'Festplatten-Zeit' von ca. 18 Jahren überhaupt nur drei Plattenausfälle, die mich betrafen, eine 400-MByte-Platte von Conner (-ot 5y), eine 5-GByte-WD-Platte (! -ot 2y) und eine IBM-Platte mit 80 GByte (-ot 5y). Meine dritte private Platte, eine 2-GByte-IBM läuft heute noch - nach ca. 16 (!) Jahren - in meinem Pentium-133-Router mit AT-Board -- lärmend aber zuverlässig im Keller.

Aber mit einem init 1 wird die Platte ja gar nicht ausgeschaltet. Und die zusätzlichen Kopfbewegungen für die normalen Prüfen mit efsck sollten bei solchen Systemen nicht so extrem sein, dass man es an der Lebensdauer wirklich merkt. [...]

Das sehe ich auch so, denn gemessen an der Beanspruchung im normalen Betrieb findet ein Dateisystem-Check ja immer noch recht selten statt.

Was ich Thomas allerdings raten würde, wäre mal ein smart-Test in der Einstellung long - dann wird die Platte wirklich mal geprüft.

Ich werde das sicher machen, also mit smartctl -t long /dev/sdb. Was ist mit der Option '-C' dem Captive Mode? Ehrlich habe ich nicht so recht verstanden, was es damit auf sich hat.

Wenn auch das ohne weitere Fehlermeldungen abgeht,

Damit rechne ich eigentlich :-) denn ich tippe doch eher auf Fehler im Dateisystem-Code. Vielleicht ist es aber auch so, dass Dateisystem-Codes nicht sehr tolerant gegenüber statistisch immer mal wieder auftretenden Schreibproblemen sind, was meine ursprüngliche Frage, ob Inkonsistenzen in Dateisystemen mit zunehmender Uptime erklärbar wären, vielleicht im Ansatz beantworten könnte. Das würde auch erklären, warum häufigere FS-Checks solche Probleme vermeiden helfen, da gelegentliche harmlose Reparaturen, bzw. Wiederherstellung der Konsistenz mithilfe des Journals das Anhäufen von Konsistenzproblemen verhindern könnten. Das müsste man mal weiterverfolgen.

würde ich mir doch mal die Verkabelung ansehen, vielleicht mal die SATA-Kabel gegen neue tauschen. Obwohl: auch das würde ja normalerweise im smart-log auftauchen.

Ja, aber was mir bei der Montage diverser Rechner aufgefallen ist, dass es sehr unterschiedliche Qualitäten bei SATA-Buchsen auf Mainboards und auch bei den Steckern an den Kabeln gibt: während die einen schön satt einrasten und dann gut festsitzen, wackeln andere beinahe wie ein Kuhschwanz vor sich hin. Mir ist schleierhaft, dass ich da nicht schon mehr Probleme beobachtet habe. Genau einmal habe ich das bei einem eSATA-Anschluß in einem Kartenleser gehabt, nämlich ständige I/O-Fehler. Zum Glück hat das Board noch eine eSATA-Buchse in der ATX-Blende, wo das Kabel hervorragend einrastet. Schönen Abend allerseits, 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