ext[23] und reiser unzuverlässig bei langer Uptime? ext4 besser?
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 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? Was machen denn Betreiber von großen Serverfarmen? Setzen die andere, als zuverlässiger bekannte Dateisysteme ein? 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. 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. Gibt es Möglichkeiten der Früherkennung? Ich denke an Konsistenz-Checks der _gemounteten_ Dateisysteme. Geht so etwas? Danke für Eure Tipps schon im Voraus! Gruß, Tom P.S.: Backups habe ich natürlich -- in Form von Dateisystem-Snapshots. -- 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
Thomas Michalka
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.
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,
Was machen denn Betreiber von großen Serverfarmen? Setzen die andere, als zuverlässiger bekannte Dateisysteme ein?
Das ist abhängig vom Betriebssystem. Häufig wird ein Storage Area Network (San) benutzt, als Dateisystem wird dann lustre oder ähnliches eingesetzt.
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
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.
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. -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 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
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, 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.
...
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...
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. 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). 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. Es sei denn, dass es sich um eine Systemplatte handelt, die keine temporären Daten speichert und aufgrund eines großzügigen RAM-Ausbaus
... praktisch nie angesprochen würde - dann wäre ein solcher Test natürlich vergleichsweise die absolute Beanspruchung ;-) 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. Wenn auch das ohne weitere Fehlermeldungen abgeht, 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. Gruß Martin -- 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
Am 17. März 2010 14:08 schrieb Thomas Michalka
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
smartd läuft? Gruß Martin -- 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
On 17.03.2010, Thomas Michalka wrote:
innerhalb weniger Tage hatte ich auf verschiedenen Systemen Ärger mit den genannten Dateisystemen, nur in einem Fall nach einem kurzen Stromausfall, letzteres trotz Journalling.
Das kann passieren und ist leider manchmal nicht vermeidbar. Es sei denn, man akzeptiert, dass jegliches caching abgeschaltet ist, und damit die Performance auf ein wirklich unertraegliches Mass sinkt.
Werden Dateisysteme mit zunehmender Uptime generell inkonsistenter?
Nein, eher nicht, da es fuer die Festplatten schonender ist.
Was machen denn Betreiber von großen Serverfarmen? Setzen die andere, als zuverlässiger bekannte Dateisysteme ein?
Das kann man pauschal so nicht beantworten. Das Stichwort hier ist, wie in allen solchen und aehnlich gelagerten Faellen "backup".
Was setzt Ihr für Dateisysteme auf lang laufenden Servern ein? Oder lasst Ihr sie nicht über Monate durchlaufen?
Ich verwende seit Jahren ausschliesslich XFS.
Was denkt Ihr über ext4? Ist ja noch nicht so lang im Praxistest.
Ich denke, es enthaelt noch zu viele Bugs fuer einen wirklich langen und stabilen Betrieb.
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.
Das kostet mehr Zeit, Nerven und Ressourcen als es nuetzt. Ich halte es fuer absolut unnoetig und sinnlos.
Gibt es Möglichkeiten der Früherkennung? Ich denke an Konsistenz-Checks der _gemounteten_ Dateisysteme. Geht so etwas?
Dafuer gibt es z.B. smart, alles andere Sinnvolle muendet in einer durchdachten und stabilen Backup Struktur. -- 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
Am Wed, 17 Mar 2010 18:46:30 +0100
schrieb Heinz Diehl
On 17.03.2010, Thomas Michalka wrote:
[...]
Was setzt Ihr für Dateisysteme auf lang laufenden Servern ein? Oder lasst Ihr sie nicht über Monate durchlaufen?
Ich verwende seit Jahren ausschliesslich XFS.
[...] Wenn wir schon mal wieder einen Filesystrem Thread haben, möchte ich meinen Senf dazugeben, speziell zu xfs. Xfs ist sicherlich geeignet für große Dateien, die ihre Größe nicht verändern, wenn Dateien aber ständig ihre Größe verändern, werden Schreiboperationen sehr, sehr langsam. Am Beispiel von OpenLDAP, ein ldapdelete von ca. 10.000 Einträgen dauert unter xfs ca. 45 Minuten, unter btrfs ca. 35 Minuten, mit ext3 ca. 15 Minuten. Ein OpenLDAP mit ca. 10Mio Einträgen war mit xfs nicht zu betreiben, ständige Deadlocks der BerkeleyDB. Nach einer Portierung auf ext3 war der Spuk vorbei, keine Performance-Probleme, keine Deadlocks, akzeptable Schreiboperationen. -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
participants (5)
-
Dieter Kluenter
-
Heinz Diehl
-
Martin Hofius
-
Martin Schröder
-
Thomas Michalka