N'abend zusammen ! Ich hatte heute ein merkwürdiges Problem auf meinem Server. Der Rechner blieb nach wochenlangen Dauerlauf auf einmal stehen. Mit Alt+F10 sah ich, dass der Prozess squid einen Kernel Panic verursacht hat. "Aiee-Killing interrupt handler - no syncing" oder so war die letzte Zeile. Reboot. 5 Minuten später das selbe. Reboot. U.s.w. Alles fummeln brachte nichts (Patche einspielen etc.) bis ich die Root-Partition mal mit reiserfsck testete. Und siehe da, da waren viele Fehler, die ich nur mit --rebuild-tree beheben konnte. Dann ging wieder alles - im Squid-Cache Verzeichnis waren Dateisystemfehler. So, bei einem völlig anderen Rechner ist mit sowas öfters mit Postfix und seinen spool-Verzeichnissen passiert. Das Replay des Journals beim Booten hatte also die Fehler durch den Absturz nicht behoben. Kennt jemand so ein Verhalten, ist ReiserFS so empfindlich gegenüber Abstürzen. Oder muß ich in Abständen manuell mit reiserfsck die Partitionen checken, was ja übel wäre, denn checken kann ich ja nur, wenn die Partition "Read-Only" oder unmounted ist. Für jede Antwort bin ich dankbar. Gruß, Michel
Hallo, Am Fri, 16 Apr 2004, Michael Paarmann schrieb:
Der Rechner blieb nach wochenlangen Dauerlauf auf einmal stehen. Mit Alt+F10 sah ich, dass der Prozess squid einen Kernel Panic verursacht hat. "Aiee-Killing interrupt handler - no syncing" oder so war die letzte Zeile.
Reboot. 5 Minuten später das selbe. Reboot. U.s.w.
Alles fummeln brachte nichts (Patche einspielen etc.) bis ich die Root-Partition mal mit reiserfsck testete. Und siehe da, da waren viele Fehler, die ich nur mit --rebuild-tree beheben konnte. Dann ging wieder alles - im Squid-Cache Verzeichnis waren Dateisystemfehler. [..] Kennt jemand so ein Verhalten, ist ReiserFS so empfindlich gegenüber Abstürzen.
Schau ins Archiv der Liste... -dnh, sich weitere Bemerkungen verkneifend -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo Michel,
Kennt jemand so ein Verhalten, ist ReiserFS so empfindlich gegenüber Abstürzen. Oder muß ich in Abständen manuell mit reiserfsck die Partitionen checken, was ja übel wäre, denn checken kann ich ja nur, wenn die Partition "Read-Only" oder unmounted ist.
Ich hatte mein System bisher auch auf ReiserFS und kenne die Problematik nur zu gut. Ich musste einmal das System gnadenlos mit Stecker ziehen beruhigen. Danach war es wie bei Dir, ReiserFS war nur noch read-only zu mounten um dann fsck durchzuführen. Viele Dateisystemfehler wurden gefunden und repariert. Aber ab diesem einen Absturz ist ReiserFS immer anfälliger geworden gegen Dateisystem Probleme. Einmal hatte es sogar den hotplug Dienst erwischt... Inzwischen nutze ich xfs und bin begeistert! Lieber Gruß Can
Can-Carlo Dörtbudak
Kennt jemand so ein Verhalten, ist ReiserFS so empfindlich gegenüber Abstürzen. Oder muß ich in Abständen manuell mit reiserfsck die Partitionen checken, was ja übel wäre, denn checken kann ich ja nur, wenn die Partition "Read-Only" oder unmounted ist.
Ich hatte mein System bisher auch auf ReiserFS und kenne die Problematik nur zu gut.
Nein. Was Du im Folgenden schilderst, ist etwas *vollkommen* anderes. Das hat mit dem Dateisystem nicht das geringste zu tun.
Ich musste einmal das System gnadenlos mit Stecker ziehen beruhigen.
Von dieser Vorgehensweise ist nämlich *absolut* abzuraten. Wenn es denn unbedingt sein muß, dann nimm wenigstens den Reset-Schalter.
Danach war es wie bei Dir, ReiserFS war nur noch read-only zu mounten um dann fsck durchzuführen.
Da kannst Du doch froh sein. Dein Dateisystem - vollkommen egal welches - kann nach so einer Aktion nämlich auch einfach weg sein oder sich zumindest in irreparablem (und unlesbarem) Zustand befinden. Zur Problematik des OP kann man eigentlich nur sagen: typisch, auch wenn's keine Beweise gibt. Alles konstruktive dazu ist schon gesagt worden. ;-) Martin
On Sat, Apr 17, 2004 at 07:10:35PM +0200, Martin Schmitz wrote:
Da kannst Du doch froh sein. Dein Dateisystem - vollkommen egal welches - kann nach so einer Aktion nämlich auch einfach weg sein oder sich zumindest in irreparablem (und unlesbarem) Zustand befinden.
Du meinst es wär normal das ein Dateisystem nach einem plötzlichem Stromverlust sich selbst zerstört? .. also ich würd das _nicht_ Als normal empfinden. Ich mag falsch liegen, aber für das Dateisystem macht es doch keinen Unterschied ob man den Rechner ausmacht (stecker zieht .. wasauchimmer) oder ob man den Reset-Knopf drückt.
Frank.Wehrsenger, Sonntag, 18. April 2004 17:22:
Du meinst es wär normal das ein Dateisystem nach einem plötzlichem Stromverlust sich selbst zerstört? .. also ich würd das _nicht_ Als normal empfinden.
Normal oder nicht ist hier nicht die Frage. Ein Stromverlust (plötzlich, wie sonst) bringt ein FS in einen undefinierten Zustand, und da kann es halt auch einen Schaden kriegen.
Ich mag falsch liegen, aber für das Dateisystem macht es doch keinen Unterschied ob man den Rechner ausmacht (stecker zieht .. wasauchimmer) oder ob man den Reset-Knopf drückt.
Das macht auch keinen Unterschied. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Donnerstag, 15. April 2004 23:48 schrieb Michael Paarmann:
Kennt jemand so ein Verhalten, ist ReiserFS so empfindlich gegenüber Abstürzen. Oder muß ich in Abständen manuell mit reiserfsck die Partitionen checken, was ja übel wäre, denn checken kann ich ja nur, wenn die Partition "Read-Only" oder unmounted ist.
irgendwie haben zu viele leute mit ReiserFS schlechte Erfahrungen gemacht (mich eingeschlossen), dass es noch irgendwie Zufall sein koennte. Ich nehme inzwischen EXT3: vielleicht nicht State of the Art, aber zumindest Rock Solid.. cu stonki -- www.stonki.de: the more I see, the more I know....... www.proftpd.de: Deutsche ProFTPD Dokumentation www.krename.net: Der Batch Renamer für KDE www.kbarcode.net: Die Barcode Solution für KDE
Am Freitag, 16. April 2004 08:20 schrieb Stefan Onken:
irgendwie haben zu viele leute mit ReiserFS schlechte Erfahrungen gemacht (mich eingeschlossen), dass es noch irgendwie Zufall sein koennte. Ich nehme inzwischen EXT3: vielleicht nicht State of the Art, aber zumindest Rock Solid..
Full ACK Wolfgang
Michael Paarmann wrote:
Ich hatte heute ein merkwürdiges Problem auf meinem Server.
Welche SuSE-Version? Welcher Kernel?
[...] Das Replay des Journals beim Booten hatte also die Fehler durch den Absturz nicht behoben.
Es waere (deswegen die Frage nach der Kernel-Version) moeglich, dass es sich hier um einen Kernel-Bug handelt. Es waere aber auch moeglich, dass die Folgen des reinen Absturzes beseitigt wurden, aber zusaetzlich (evtl. bereits vorher) weitere Dateisystemfehler vorhanden waren bzw. sind. Die werden durch Auswerten der Journalinformationen natuerlich nicht korrigiert. Hast Du neben dem Filesystem auch mal die Festplatte selbst ueberprueft? Da boete sich das Tool Deines Festplattenherstellers an (die bieten eigentlich alle entsprechende Programme an) oder aber z.B. badblocks.
[...] Kennt jemand so ein Verhalten, ist ReiserFS so empfindlich gegenüber Abstürzen. Oder muß ich in Abständen manuell mit reiserfsck die Partitionen checken, was ja übel wäre, denn checken kann ich ja nur, wenn die Partition "Read-Only" oder unmounted ist.
Du solltest immer, wenn sich die Gelegenheit dafuer bietet, auch bei Verwendung eines Jounaling Filesystems einen Filesystemcheck machen. Mache ihn dann, wenn Du z.B. eh gerade Rebooten musst (wie man einen Check erzwingen kann, solltes Du natuerlich wissen), oder Zeit hast und ein Reboot mit laengerer Downzeit nichts ausmacht, etc. Viele Erfahrungen mit ReiserFS auch auf dieser Liste zeigen, dass es anscheinend tatsaechlich etwas anfaelliger ist als andere Dateisysteme, insbesondere wenn die Hardware darunter nicht 100% einwandfrei ist (deswegen auch der Hinweis auf badblocks etc.). Wenn Du meine persoenliche Meinung hoeren willst: lass ReiserFS aussen vor und verwende ein anderes Dateisystem. Das ist unser Erfahrungswert hier. Wir kommen hier mit einer Kombination aus ext2/3 und xfs sehr gut zurecht. CU, Th.
Danke für eure Antworten. Dann scheint es ja so, als ob ReiserFS wirklich nicht das Gelbe vom Ei ist. Ich hatte die Platten getestet (alles SCSI-Platten von Seagate) und sie waren fehlerfrei.
Welche SuSE-Version? Welcher Kernel?
Da Problem trat bei einem SuSE Emailserver 3.1 mit Kernel 2.4.18 und bei einem SuSE 9.0 mit Kernel 2.4.21-99 auf. Probleme mit den Komponenten, die ich einsetze oder mit ReiserFS sind bei diesen, glaube ich, nicht bekannt.
Du solltest immer, wenn sich die Gelegenheit dafuer bietet, auch bei Verwendung eines Jounaling Filesystems einen Filesystemcheck machen. Mache ihn dann, wenn Du z.B. eh gerade Rebooten musst (wie man einen Check erzwingen kann, solltes Du natuerlich wissen), oder Zeit hast und ein Reboot mit laengerer Downzeit nichts ausmacht, etc.
Hmm, wenn ich nicht vor dem Rechner stehe, sondern remote darauf arbeite, wird es aber schwer, da ich einen reiserfsck nur mit einem read-only-Mount machen kann - schlecht bei der Root-Partition, oder ? Zudem hatte ich immer(!) Fehler, die ich nur mit --rebuild-tree beseitigen konnte. Ext2 ist auch nicht so toll, da ich ja öfters eine manuelle Eingabe beim FSCK machen muß. Remote ist das auch schlecht. Sind die anderen Filesysteme da besser? Es kommt mir nicht auf Performance an, sondern das Filesystem soll einfach nur robust sein. Mit ext3 und xfs habe ich noch keine Erfahrungen, ich hab nur ext2 und reiser intensiv probiert.
Viele Erfahrungen mit ReiserFS auch auf dieser Liste zeigen, dass es anscheinend tatsaechlich etwas anfaelliger ist als andere Dateisysteme, insbesondere wenn die Hardware darunter nicht 100% einwandfrei ist (deswegen auch der Hinweis auf badblocks etc.). Wenn Du meine persoenliche Meinung hoeren willst: lass ReiserFS aussen vor und verwende ein anderes Dateisystem.
Welches sollte ich denn für einen Rechner, der nur remote gewartet wird, am besten einsetzen? Was denkt ihr? Danke im voraus ! Michel
Am Freitag, 16. April 2004 12:42 schrieb Michael Paarmann:
Danke für eure Antworten.
[...]
Ext2 ist auch nicht so toll, da ich ja öfters eine manuelle Eingabe beim FSCK machen muß. Remote ist das auch schlecht.
Kann ich so nicht bestätigen. Wenn es wirklich größere Probleme gab, war meistens die Platte hin. Das hatten wir häufiger in letzter Zeit, und nicht nur bei Linux. In letzter Zeit legen wir bei jedem remote-Rechner eine knoppix bei. Mit ein paar Eingaben kann der Benutzer knoppix booten und eine Verbindung zu uns aufbauen, falls der Rechner gar nicht mehr startet. Da wäre auch ein fsck mit interaktiven Eingaben möglich.
Sind die anderen Filesysteme da besser? Es kommt mir nicht auf Performance an, sondern das Filesystem soll einfach nur robust sein. Mit ext3 und xfs habe ich noch keine Erfahrungen, ich hab nur ext2 und reiser intensiv probiert.
Ext3 ist (fast) nichts anderes als ext2, es ist dazu kompatibel. Nur die Journaling-Funktionen sind daraufgesetzt. Hat sich bei uns auch remote als sehr stabil erwiesen. Gruß, Wolfgang
Am Freitag April 16 2004 12:42 schrieb Michael Paarmann:
Sind die anderen Filesysteme da besser? Es kommt mir nicht auf Performance an, sondern das Filesystem soll einfach nur robust sein. Mit ext3 und xfs habe ich noch keine Erfahrungen, ich hab nur ext2 und reiser intensiv probiert. [...] Welches sollte ich denn für einen Rechner, der nur remote gewartet wird, am besten einsetzen? Was denkt ihr?
ext3 ist ein ext2 + Journaling Funktion. Das hat sich als sehr robust erwiesen. Ich kann hier aus eigener Erfahrung reden, da ich mit einigen Kerneln auf meiner Hardware große Probleme hatte. Da ist mir kurz hintereinander das System mehrfach weggeblieben - ein Reboot war kein Thema. Lief immer wieder hoch, ohne mich mit dem Single-User-Mode zu begrüßen. ext2 auf etwas älteren Kerneln hätte da vermutlich recht schnell die Flügel gestreckt. Auch mißhandelte Linuxe, die als Router dienen, vertrugen das einfach mal schnell den Stecker ziehen und versehentliches Ausschalten. (Kunden machen das halt schon mal gerne; Windowsadmins auch). Ein einziges Mal mußte ich tatsächlich per Telefon jemanden einen Plattencheck machen lassen, damit die Kiste wieder normal startete. Als repräsentativ würde ich das jedoch nicht ansehen. Ich jedenfalls setze ext3 sehr gerne ein. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Michael Paarmann wrote:
[...]
Bitte lasse beim Zitieren eine Einleitung stehen, wer den Text, den Du zitierst, geschrieben hat (sog. Attribution Line). Sonst kann das niemand mehr nachvollziehen. Danke.
Welche SuSE-Version? Welcher Kernel?
Da Problem trat bei einem SuSE Emailserver 3.1 mit Kernel 2.4.18 und bei einem SuSE 9.0 mit Kernel 2.4.21-99 auf. Probleme mit den Komponenten, die ich einsetze oder mit ReiserFS sind bei diesen, glaube ich, nicht bekannt.
Doch, sehr wohl. Kernel 2.4.18 ist schon sehr alt und er hat definitiv (sofern diese nicht gefixt wurden) einige Bugs, die u.a. zumindest lokalen Usern das Erlangen von Root-Rechten ermoeglicht. Zudem hatte der 2.4.18.SuSE (zumindest das original von SuSE) schwere Probleme bei mehr als einer IDE Festplatte im System - das scheint bei Dir aber wegen Verwendung von SCSI nicht zuzutreffen. Kernel 2.4.21-99 hat AFAIK einen Bug bei ReiserFS, der durchaus zu dem Bild, was Du dargelegt hast, passen koennte. IIRC wurde dieser Bug mit Version 2.4.21-144 behoben. Aktuell ist glaube ich 2.4.21-199. Du solltest auf alle Faelle mal dringend YOU laufen lassen auf dem PC mit der SuSE 9.0 bzw. einen neuen Kernel von Hand einspielen.
[...] Hmm, wenn ich nicht vor dem Rechner stehe, sondern remote darauf arbeite, wird es aber schwer, da ich einen reiserfsck nur mit einem read-only-Mount machen kann - schlecht bei der Root-Partition, oder ? Zudem hatte ich immer(!) Fehler, die ich nur mit --rebuild-tree beseitigen konnte.
Die Verwendung von --rebuild-tree ist eigentlich schon recht heftig. "Normale" Fehler im Filesystem sollten eigentlich automatisch korrigiert werden koennen. Allerdings habe ich kaum Erfahrung mit reiserfsck, da wir ReiserFS eben nicht mehr einsetzen und nur ab und zu mal mit rumspielen auf Test-PCs.
[...] Ext2 ist auch nicht so toll, da ich ja öfters eine manuelle Eingabe beim FSCK machen muß. Remote ist das auch schlecht.
Bei ext2 und ext3 musst Du dann Eingaben von Hand machen, wenn es sich um derart schwere Fehler im Filesystem handelt, dass diese nicht mehr automatisch korrigiert werden koennen. Ich denke, in diesem Falle wirst Du mit jedem Filesystem in Probleme kommen, wenn Du nur Remote-Zugriff hast.
Sind die anderen Filesysteme da besser? Es kommt mir nicht auf Performance an, sondern das Filesystem soll einfach nur robust sein. Mit ext3 und xfs habe ich noch keine Erfahrungen, ich hab nur ext2 und reiser intensiv probiert.
Wir verwenden hier i.d.R. ext3 und xfs und hatten bisher nie groessere Probleme damit (es sei denn, die Festplatte ging kaputt, aber diese Fehler waren dann halt nicht auf das Filesystem selbst zurueckzufuehren - wenn die Hardware versagt, wird jedes Filesystem frueher oder spaeter in die Knie gehen). CU, Th.
Hi On Friday 16 April 2004 12:42, Michael Paarmann wrote:
Dann scheint es ja so, als ob ReiserFS wirklich nicht das Gelbe vom Ei ist. Ich hatte die Platten getestet (alles SCSI-Platten von Seagate) und sie waren fehlerfrei.
Nur damit die Äußerungen hier nicht zu einseitig werden. Ich benutze seit SuSE 7.3 erschienen ist auf verschiedenen Rechnern reiserfs. Es hat auch diverses Steckerziehen überstaden. Es ist durch Auftreten von badblocks zwar einmal kaputtgegangen, aber sonst läuft es seit Jahren problemlos. Vermutlich würde ein gewisser Anteil der reiser-Kritik verschwinden, wenn es endlich mal sowas wie die -c Option bei e2fsck auch bei reiserfsck gäbe. Reiser hat auch Vorteile. Wenn man z.B. große Mengen mails in maildir oder im cyrus-Format abspeichert, dann ist ein Performancegewinn zu erwarten.
Hmm, wenn ich nicht vor dem Rechner stehe, sondern remote darauf arbeite, wird es aber schwer, da ich einen reiserfsck nur mit einem read-only-Mount machen kann - schlecht bei der Root-Partition, oder ? Zudem hatte ich immer(!) Fehler, die ich nur mit --rebuild-tree beseitigen konnte.
Ext2 ist auch nicht so toll, da ich ja öfters eine manuelle Eingabe beim FSCK machen muß. Remote ist das auch schlecht.
Bei e2fsck gibt es die Option -y. Bei reiserfsck, das meiner Meinung nach 97% der Kritik an reiserfs als solches verschuldet, wird -y leider ignoriert. Wobei ich nicht verstehe warum eine interaktive Dateisystemüberprüfung remote schlimmer sein sollte als wenn man davor sitzt. Ich finde beides gleich nervig :-) Das größere Problem ist, ob man sich überhaupt noch einloggen kann oder nicht. Und dann hilft es einem auch nicht wenn die Dateisystemüberprüfung ohne zwischendurch-Eingabe durchläuft.
Sind die anderen Filesysteme da besser? Es kommt mir nicht auf Performance an, sondern das Filesystem soll einfach nur robust sein. Mit ext3 und xfs habe ich noch keine Erfahrungen, ich hab nur ext2 und reiser intensiv probiert.
Ext2 und ext3 sind vom Aufbau her gleich. Man kann jedes Ext3 auch als ext2 mounten. Ext3 ist "nur" ein ums journal erweitertes ext2. Wenn es auf Performance nicht ankommt, dann kann man ruhig zu ext2/3 greifen. Da treten meiner Erfahrung nach zwar Fehler auch nicht seltener auf als bei reiser, e2fsck ist aber beim Reparieren wesentlich erfolgreicher.
Welches sollte ich denn für einen Rechner, der nur remote gewartet wird, am besten einsetzen? Was denkt ihr?
Hängt vom Einsatz deines Servers ab. Datenverlust ist bei ext weniger wahrscheinlich, dafür hat reiser die bessere Performance und Platzausnutzung, wenn es um viele kleine Dateien geht. Die Dateisystem-Frage unter linux ist häufig aber auch eine Glaubensfrage, die die Menschheit noch stärker spaltet als die nach Nass- oder Trockenrasieren. mfg Axel
Danke. Ich werde dann wohl mal xfs oder ext3 probieren. Mal sehen, Erfahrung sammelt man ja erst mit längerer Zeit...
Wobei ich nicht verstehe warum eine interaktive Dateisystemüberprüfung remote schlimmer sein sollte als wenn man davor sitzt. Ich finde beides gleich nervig :-)
Ja, wenn man nicht hunderte KM vom Server weg ist, ist's egal ;-)) Oder wenn der, der davor steht so viel Ahnung von FSCK hat wie eine Blutwurst von Kernfusion...
Das größere Problem ist, ob man sich überhaupt noch einloggen kann oder nicht. Und dann hilft es einem auch nicht wenn die Dateisystemüberprüfung ohne zwischendurch-Eingabe durchläuft.
Eben. Gut wäre, wenn ich einen FSCK im laufenden System machen könnte. Den kann ich dann ja über cron regelmäßig laufen lassen. Gibt's sowas ? Ich will ja nicht unken - ihr dürft mich schlagen - aber mit FAT oder NTFS geht sowas.
Die Dateisystem-Frage unter linux ist häufig aber auch eine Glaubensfrage, die die Menschheit noch stärker spaltet als die nach Nass- oder Trockenrasieren.
Das ist wohl wahr.... Gruß, Michel
On Fri, Apr 16, 2004 at 03:17:55PM +0200, Michael Paarmann wrote:
Eben. Gut wäre, wenn ich einen FSCK im laufenden System machen könnte. Den kann ich dann ja über cron regelmäßig laufen lassen. Gibt's sowas ? Ich will ja nicht unken - ihr dürft mich schlagen - aber mit FAT oder NTFS geht sowas.
Nein, unter Windows 2k/XP kannst du auch nicht die Root-Partition reparieren lassen. Und bei Win98/FAT32 war es früher so das er zwar scandisk durchführen konnte, aber immer nachdem 'irgendetwas' auf die platte geschrieben hat, auch wieder von vorne angefangen hat. Dieses Verhalten dürfte auf einem Server auch nicht von Nutzen sein. Bei XP/2k kann man ein vollständiges "chkdsk /f" der root-partition nur mit anschliessendem Neustart machen.
At 15:32 16.04.2004, you wrote:
On Fri, Apr 16, 2004 at 03:17:55PM +0200, Michael Paarmann wrote:
Eben. Gut wäre, wenn ich einen FSCK im laufenden System machen könnte. Den kann ich dann ja über cron regelmäßig laufen lassen. Gibt's sowas ? Ich will ja nicht unken - ihr dürft mich schlagen - aber mit FAT oder NTFS geht sowas.
Bei XP/2k kann man ein vollständiges "chkdsk /f" der root-partition nur mit anschliessendem Neustart machen.
Stimmt. Kann ich denn einen reiserfsck beim Start durchführen, der, falls es sein muß, selber --rebuild-tree macht ? Das wär's so etwa. So lange dauert das bei mir nicht, mit dem längeren hochfahren kann ich leben. Gruß, Michel
participants (11)
-
Andreas Feile -
Axel Heinrici -
Can-Carlo Dörtbudak -
David Haller -
Frank.Wehrsenger -
Helga Fischer -
Martin Schmitz -
Michael Paarmann -
Stefan Onken -
Thomas Hertweck -
Wolfgang Hinsch