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.
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 ...
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.
Den höchsten uptime Wert den ich jemals hatte war 384 Tage
Ich hatte auch einmal deutlich über ein Jahr. Da gab es keine Probleme.
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?
Gibt es Möglichkeiten der Früherkennung? Ich denke an Konsistenz-Checks der _gemounteten_ Dateisysteme. Geht so etwas?
Ein Blick auf strg+alt+f10 Wenn Fehler akut werden, dann wird nach STDERR geloggt, die Ausgabe von STDERR ist bei openSUSE auf Terminal 10.
Schaue ich schon ab und zu hin, und ich sehe hin und wieder z.B. folgendes: Mar 15 12:03:11 neptun kernel: ata3.00: exception Emask 0x10 SAct 0x1 SErr 0x780100 action 0x4 Mar 15 12:03:11 neptun kernel: ata3.00: irq_stat 0x08000000 Mar 15 12:03:11 neptun kernel: ata3: SError: { UnrecovData 10B8B Dispar BadCRC Handshk } Mar 15 12:03:11 neptun kernel: ata3.00: cmd 60/08:00:63:72:5b/00:00:36:00:00/40 tag 0 ncq 4096 in Mar 15 12:03:11 neptun kernel: res 40/00:04:63:72:5b/00:00:36:00:00/40 Emask 0x10 (ATA bus error) Mar 15 12:03:11 neptun kernel: ata3.00: status: { DRDY } Mar 15 12:03:11 neptun kernel: ata3: hard resetting link Mar 15 12:03:11 neptun kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 15 12:03:11 neptun kernel: ata3.00: configured for UDMA/133 Mar 15 12:03:11 neptun kernel: ata3: EH complete und Mar 15 12:07:41 neptun kernel: ata3: limiting SATA link speed to 1.5 Gbps Mar 15 12:07:41 neptun kernel: ata3.00: exception Emask 0x10 SAct 0x1 SErr 0x780100 action 0x4 Mar 15 12:07:41 neptun kernel: ata3.00: irq_stat 0x08000000 Mar 15 12:07:41 neptun kernel: ata3: SError: { UnrecovData 10B8B Dispar BadCRC Handshk } Mar 15 12:07:41 neptun kernel: ata3.00: cmd 60/08:00:33:70:d7/00:00:26:00:00/40 tag 0 ncq 4096 in Mar 15 12:07:41 neptun kernel: res 40/00:04:33:70:d7/00:00:26:00:00/40 Emask 0x10 (ATA bus error) Mar 15 12:07:41 neptun kernel: ata3.00: status: { DRDY } Mar 15 12:07:41 neptun kernel: ata3: hard resetting link Mar 15 12:07:41 neptun kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Mar 15 12:07:41 neptun kernel: ata3.00: configured for UDMA/133 Mar 15 12:07:41 neptun kernel: ata3: EH complete 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. Müsste der Syslog von solchen Meldungen bzgl. der Platten und ATA völlig frei sein? Aber $> smartctl -a /dev/sdb ergibt SMART overall-health self-assessment test result: PASSED Bei den einzelnen Werten kann ich nur sagen, dass die Spalte 'WHEN_FAILED' leer ist. Darin müsste ich ja auch frühere Fehler sehen. Also scheint die Platte selber in Ordnung zu sein. 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