Nach Absturz halbe Stunde warten bei ReiserFS
Hi Liste, ich habe seit kurzen einen kleinen Server. Das Root-FS ist ReiserFS: 4GB Partition, davon knapp 800MB belegt. Als ich den Server heute auf die harte Tour abschalten mußte (keine Tastatur dran und Netzwerk ausgefallen) dauerte es fast eine halbe Stunde, bis er vollständig neu gestartet war. Die Überprüfung/Reparatur des FS dauerte so lange. Dabei bekam ich dann fast 400 Mal die Meldung "clm-6006: writing inode 3634 on readonly FS". Wobei auch mal "clm-6005" und eine andere inoden-Nummer dastand. Wieso braucht ReiserFS so lange? Warum schreibt der x-hundert Mal auf die selbe inode? Als ich den Rechner ausgekippst hatte waren keine größeren Festplattenaktivitäten vorhanden. Kann mir einer sagen wie ich das abstellen/verbessern kann? Oder ist das normal? Oder soll ich Ext3 hernehmen? Hoffe ihr könnt mir helfen Martin
Martin Scharrer wrote:
ich habe seit kurzen einen kleinen Server. Das Root-FS ist ReiserFS: 4GB Partition, davon knapp 800MB belegt.
Herzliches Beileid ;-)[1]
Als ich den Server heute auf die harte Tour abschalten mußte (keine Tastatur dran und Netzwerk ausgefallen) dauerte es fast eine halbe Stunde, bis er vollständig neu gestartet war. Die Überprüfung/Reparatur des FS dauerte so lange. Dabei bekam ich dann fast 400 Mal die Meldung "clm-6006: writing inode 3634 on readonly FS".
Wobei auch mal "clm-6005" und eine andere inoden-Nummer dastand. Wieso braucht ReiserFS so lange? Warum schreibt der x-hundert Mal auf die selbe inode? Als ich den Rechner ausgekippst hatte waren keine größeren Festplattenaktivitäten vorhanden.
Naja, versuche mal auf ein Filesystem zu schreiben, was read- only gemountet ist - da braeuchtest Du vermutlich auch so einige Versuche.... ;-) Ich nehme an, dass er immer und immer wieder versucht zu schreiben und dann irgendwann aufgibt, so etwa nach einer halben Stunde. Und dann wird wahrscheintlich weiter gebootet, das Problem besteht aber fort! Du solltest also Dich dringend darum kuemmern.
Kann mir einer sagen wie ich das abstellen/verbessern kann? Oder ist das normal?
Root-Filesystem read-write mounten beim Booten. Du solltest vielleicht mal extern booten von Knoppix-CD[2] und dann das Filesystem von dort mit reiserfsck ueberpruefen. Wie man das Filesystem read-write mounted beim Booten, kann ich Dir nur beim Einsatz von lilo sagen: dort musst Du die Zeile "read-only" durch "read-write" ersetzen und dann lilo auf- rufen.
Oder soll ich Ext3 hernehmen?
Das hat glaube ich erst einmal nichts mit Deinem Problem zu tun. Ich selbst hatte mit ReiserFS nur Probleme, andere fin- den es gut und es laeuft prima bei ihnen. Behebe erst einmal Dein Problem und wenn dann wieder alles laeuft, dann bleibe bei ReiserFS. Es ist auf alle Faelle moderner und laesst bes- sere Optimierungen zu als ext3 - das hat halt den Vorteil, rueckwaertskompatibel zu sein. Wir haben hier daneben noch xfs im Einsatz, das macht eigentlich auch einen guten Eindruck. Gruesse, Thomson [1] Ja, ich weiss, viele Leute sind mit ReiserFS zufrieden. Ich aber nicht - habe schon zu viele Probleme damit erlebt.... [2] http://www.knopper.net/knoppix/ -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
On Thursday 02 January 2003 10:39, Thomas Hertweck wrote:
des FS dauerte so lange. Dabei bekam ich dann fast 400 Mal die Meldung "clm-6006: writing inode 3634 on readonly FS". Naja, versuche mal auf ein Filesystem zu schreiben, was read- only gemountet ist - da braeuchtest Du vermutlich auch so einige Versuche.... ;-) Ich nehme an, dass er immer und immer wieder versucht zu schreiben und dann irgendwann aufgibt, so etwa nach einer halben Stunde. Und dann wird wahrscheintlich weiter gebootet, das Problem besteht aber fort! Du solltest also Dich dringend darum kuemmern. Mein einziges Problem ist, dass das Booten so lange dauert. Die Daten auf der Partition sind durchwegs i.O.
Kann mir einer sagen wie ich das abstellen/verbessern kann? Oder ist das normal?
Root-Filesystem read-write mounten beim Booten. Du solltest vielleicht mal extern booten von Knoppix-CD[2] und dann das Filesystem von dort mit reiserfsck ueberpruefen. Wie man das Filesystem read-write mounted beim Booten, kann ich Dir nur beim Einsatz von lilo sagen: dort musst Du die Zeile "read-only" durch "read-write" ersetzen und dann lilo auf- rufen. Ok, hab ich gemacht. Jetzt überspringt fsck die Root-Partition komplett wegen dem read-write-Mounting. Es muss doch eine einfache Möglichkeit geben nach einem "normalen" Absturz des Systems eine normale Wiederherstellung des Jornals zu bekommen. Macht Ext3 ja auch. Jetzt bootet er zwar passend, aber ganz ohne fsck möchte ich ihn auch nicht lassen.
Oder soll ich Ext3 hernehmen?
Das hat glaube ich erst einmal nichts mit Deinem Problem zu tun. Ich selbst hatte mit ReiserFS nur Probleme, andere fin- Das glaub ich eben schon. Mit allen nicht ReiserFS -(Root)-Partitionen hatte ich dieses Problem nicht.
Übrigens: Mein System ist eine frische SuSE 7.3 Installation Grüße Martin
----- Original Message ----- From: Martin Scharrer To: suse-linux@suse.com Sent: Thursday, January 02, 2003 1:35 PM Subject: Re: Nach Absturz halbe Stunde warten bei ReiserFS On Thursday 02 January 2003 10:39, Thomas Hertweck wrote:
des FS dauerte so lange. Dabei bekam ich dann fast 400 Mal die Meldung "clm-6006: writing inode 3634 on readonly FS". Naja, versuche mal auf ein Filesystem zu schreiben, was read- only gemountet ist - da braeuchtest Du vermutlich auch so einige Versuche.... ;-) Ich nehme an, dass er immer und immer wieder versucht zu schreiben und dann irgendwann aufgibt, so etwa nach einer halben Stunde. Und dann wird wahrscheintlich weiter gebootet, das Problem besteht aber fort! Du solltest also Dich dringend darum kuemmern. Mein einziges Problem ist, dass das Booten so lange dauert. Die Daten auf der Partition sind durchwegs i.O.
Kann mir einer sagen wie ich das abstellen/verbessern kann? Oder ist das normal?
Root-Filesystem read-write mounten beim Booten. Du solltest vielleicht mal extern booten von Knoppix-CD[2] und dann das Filesystem von dort mit reiserfsck ueberpruefen. Wie man das Filesystem read-write mounted beim Booten, kann ich Dir nur beim Einsatz von lilo sagen: dort musst Du die Zeile "read-only" durch "read-write" ersetzen und dann lilo auf- rufen. Ok, hab ich gemacht. Jetzt überspringt fsck die Root-Partition komplett wegen dem read-write-Mounting.
Das sollte bei einem Journaling Filesystem wie ReiserFS eigentlich auch so sein. I.d.R. sind die Meldungen beim Wiederherstellen so kurz, dass diese leicht übersehen werden können. Es wird dann irgendetwas wie .... Transaction Log .... gemeldet. Vorgangsdauer unter 1-2 Sekunden bei Partitionen <40 GB AFAIK ist es sowieso gefährlich einen Reiserfschk zu benutzen. Es wird dringend auf den Betastatus des Programms hingewiesen, ich selber hatte aber bisher noch keine Probleme damit. Es muss doch eine einfache Möglichkeit geben nach einem "normalen" Absturz des Systems eine normale Wiederherstellung des Jornals zu bekommen. Macht Ext3 ja auch. Jetzt bootet er zwar passend, aber ganz ohne fsck möchte ich ihn auch nicht lassen.
Oder soll ich Ext3 hernehmen?
Das hat glaube ich erst einmal nichts mit Deinem Problem zu tun. Ich selbst hatte mit ReiserFS nur Probleme, andere fin- Das glaub ich eben schon. Mit allen nicht ReiserFS -(Root)-Partitionen hatte ich dieses Problem nicht.
Übrigens: Mein System ist eine frische SuSE 7.3 Installation Grüße Martin -- Mit freundlichem Gruß Torsten Weckmann Mail: linux@icw-gmbh.de
Martin Scharrer wrote:
On Thursday 02 January 2003 10:39, Thomas Hertweck wrote: [...] Mein einziges Problem ist, dass das Booten so lange dauert. Die Daten auf der Partition sind durchwegs i.O.
Na, dann ist das ja schon mal ganz OK. Ist bei ReiserFS ja nicht immer der Fall :-)
[...] Wie man das Filesystem read-write mounted beim Booten, kann ich Dir nur beim Einsatz von lilo sagen: dort musst Du die Zeile "read-only" durch "read-write" ersetzen und dann lilo auf- rufen.
Ok, hab ich gemacht. Jetzt überspringt fsck die Root-Partition komplett wegen dem read-write-Mounting. Es muss doch eine einfache Möglichkeit geben nach einem "normalen" Absturz des Systems eine normale Wiederherstellung des Jornals zu bekommen. Macht Ext3 ja auch. Jetzt bootet er zwar passend, aber ganz ohne fsck möchte ich ihn auch nicht lassen.
Bei ext3 wird auch kein fsck durchgefuehrt, sondern lediglich das Log geprueft. Wenn Du die Anleitung zu ext3 liest, dann steht dort auch, dass man (zumindest wenn man mit tune2fs und den Optionen -c und -i das Ueberpruefen abgestellt hat) selbst fuer regelmaessige Ueberpruefungen des Filesystems zustaendig ist. Hat man das Ueberpruefen nicht abgestellt, so wird wie bisher bei ext2 auch bei ext3 alle soundsoviel Reboots bzw. al- le soundsoviel Tage ein fsck durchgefuehrt. Der Vorteil bei ext3 und dem Abschalten der Ueberpruefung ist halt, man kann sie dann machen, wenn man gerade Zeit hat oder sonst etwas anliegt. Das wird bei ReiserFS aehnlich sein, es wird sicher nur das Log ueberprueft - Du unterliegst da also wohl einem Irrtum wenn Du denkst, dass bei jedem Booten ein fsck gemacht wird. Schau beim Booten mal genau hin - ich denke nicht, dass er da was ueberspringt, ich denke, er wird das Log pruefen und gege- benenfalls etwas unternehmen. Das geht aber so schnell, dass Du es kaum bemerken duerftest. Gruesse, Th. -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
On Thursday 02 January 2003 15:46, Thomas Hertweck wrote:
Martin Scharrer wrote:
On Thursday 02 January 2003 10:39, Thomas Hertweck wrote: [...] Mein einziges Problem ist, dass das Booten so lange dauert. Die Daten auf der Partition sind durchwegs i.O.
Na, dann ist das ja schon mal ganz OK. Ist bei ReiserFS ja nicht immer der Fall :-) Ist ein diese Woche aufgesetzter privater Server. Soo schlimm wäre das nicht, obwohl mich dass nach nur einmal Power-Off erschrecken würde.
Macht Ext3 ja auch. Jetzt bootet er zwar passend, aber ganz ohne fsck möchte ich ihn auch nicht lassen.
Bei ext3 wird auch kein fsck durchgefuehrt, sondern lediglich das Log geprueft. Wenn Du die Anleitung zu ext3 liest, dann steht dort auch, dass man (zumindest wenn man mit tune2fs und den Optionen -c und -i das Ueberpruefen abgestellt hat) selbst fuer regelmaessige Ueberpruefungen des Filesystems zustaendig ist. Hat man das Ueberpruefen nicht abgestellt, so wird wie bisher bei ext2 auch bei ext3 alle soundsoviel Reboots bzw. al- le soundsoviel Tage ein fsck durchgefuehrt. Hä, ich meine nicht bei jedem Reboot. Sondern nur nach einen Crash. Als ich mal Ext3 hatte stand da immer "Recovery Journal" oder so...
Der Vorteil bei ext3 und dem Abschalten der Ueberpruefung ist halt, man kann sie dann machen, wenn man gerade Zeit hat oder sonst etwas anliegt. Das wird bei ReiserFS aehnlich sein, es wird sicher nur das Log ueberprueft - Du unterliegst da also wohl einem Irrtum wenn Du denkst, dass bei jedem Booten ein fsck gemacht wird. S.o. meinte nach einem Crash
Schau beim Booten mal genau hin - ich denke nicht, dass er da was ueberspringt, ich denke, er wird das Log pruefen und gege- benenfalls etwas unternehmen. Das geht aber so schnell, dass Du es kaum bemerken duerftest. Da steht so was wie 'Can't fsck , filesystem is not read-only'.
Ich bin nun so verweilt: Hab in Lilo "read-write" angeben und in der /etc/fstab die beiden letzten Einträge in "0 0" geändert, da dies eine Inet-Quelle so empfahl. [Die erste Null steht übrigens dafür ob das FS "gedumpt"(?) werden soll/kann/darf (?). Die zweite gibt die Reihenfolge für den fsck an (0 = gar nicht, 1 = root, 2 = andere). ] "Da Reiserfs beim starten nicht geprüft werden muß". Na ja, hoffentlich stimmt das. Aber die Alternative mit den langen Warten ist nicht akzeptabel. Wird so schon funktionieren. Vielen Dank für deine Hilfe Martin
Martin Scharrer wrote:
[...] Hab in Lilo "read-write" angeben und in der /etc/fstab die beiden letzten Einträge in "0 0" geändert, da dies eine Inet-Quelle so empfahl. [Die erste Null steht übrigens dafür ob das FS "gedumpt"(?) werden soll/kann/darf (?). Die zweite gibt die Reihenfolge für den fsck an (0 = gar nicht, 1 = root, 2 = andere). ] "Da Reiserfs beim starten nicht geprüft werden muß". Na ja, hoffentlich stimmt das. Aber die Alternative mit den langen Warten ist nicht akzeptabel.
Ich habe so das Gefuehl, Du hast den Unterschied zwischen einem Festplattencheck via fsck (sei es fsck.ext3 oder reiserfsck) und dem Ueberpruefen des Log-Files mit evtl. anschliessender Korrek- tur am Filesystem nicht ganz verstanden. Schau doch mal, wenn es Dich doch naeher interessieren sollte, ob Du da nicht via google ein paar Details zu findest - meine kurzen Erlaeuterungen haben wohl nicht ausgereicht. Gruesse, Th. -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Hi Thomas On Friday 03 January 2003 15:35, Thomas Hertweck wrote:
Ich habe so das Gefuehl, Du hast den Unterschied zwischen einem Festplattencheck via fsck (sei es fsck.ext3 oder reiserfsck) und dem Ueberpruefen des Log-Files mit evtl. anschliessender Korrek- tur am Filesystem nicht ganz verstanden. Schau doch mal, wenn es Dich doch naeher interessieren sollte, ob Du da nicht via google ein paar Details zu findest - meine kurzen Erlaeuterungen haben wohl nicht ausgereicht. Ok, ich geb zu, dass ich den "Festplattencheck via fsck" und das "Ueberpruefen des Log-Files mit evtl. anschliessender Korrektur am Filesystem" in meinen Postings nicht so getrennt dargestellt habe wie es nötig gewesen wäre. Was der grundlegende Unterschied dazwischen ist ist und war mir klar. Ich dachte allerdings, das "fsck" für beides zuständig ist und nur mit einem anderen Modus (d.h. mit einem anderen Parameter) gestartet wird. Liege ich da falsch?
Deshalb hatte ich meine Sorge wegen der "Skipping fsck because root partition is read-write" (oder so) Meldung. Ich schloß daraus, dass das Journal jetzt überhaupt nicht mehr hergestellt wird. Als ich in meinen letzten Postings denn Ausdruck "fsck" verwendete meinte ich immer das "Ueberpruefen des Log-Files mit evtl. anschliessender Korrektur am Filesystem". Genau das soll mein reiserfs nach einem Crash machen. Und zwar gut und schnell und ohne 400 Fehlermeldungen bei 20 - 30 Minuten Dauer. Sollten danach (nach dem Booten nach dem Crash) noch Fehler auf dem System vorhanden sein, die ich mit einem manuellen kompletten fsck der gesamten Platte beheben muß/soll, dann will ich _eine_ entsprechende Meldung.
Martin wrote: Ok, hab ich gemacht. Jetzt überspringt fsck die Root-Partition komplett wegen dem read-write-Mounting. Es muss doch eine einfache Möglichkeit geben nach einem "normalen" Absturz des Systems eine normale Wiederherstellung des Jornals zu bekommen. Macht Ext3 ja auch. Hier spielt die Musik. Als ich noch Ext3 hatte kam nach einem Crash immer so was wie: "Restoring Journal" oder so beim Booten. Dauerte meißt nur wenige 10 Sekunden , allenfalls mal 2 Minuten. Sowas will ich auch bei Reiserfs.
Wie gesagt, inzwischen läufts passend. Und die genauen Aufrufe/Unterschiede bei den einzelnen Checks/Reperaturen werd ich mir bei einer passenden Gelegenheit mal reinziehen. Danke für deine Hilfe und deine Geduld Martin
Martin Scharrer wrote:
[...] ich geb zu, dass ich den "Festplattencheck via fsck" und das "Ueberpruefen des Log-Files mit evtl. anschliessender Korrektur am Filesystem" in meinen Postings nicht so getrennt dargestellt habe wie es nötig gewesen wäre. Was der grundlegende Unterschied dazwischen ist ist und war mir klar. Ich dachte allerdings, das "fsck" für beides zuständig ist und nur mit einem anderen Modus (d.h. mit einem anderen Parameter) gestartet wird. Liege ich da falsch?
Hier ein Auszug aus der ReiserFS-FAQ: o Q: Why are ReiserFS filesystems not fscked on reboot after a crash? A: Because ReiserFS provides journalling of meta-data. After a crash, the consistency of a filesystem is restored by replaying the transaction log. Ebenso steht dort: o Q: What should I put into the fifth (aka dump, fs_freq ) and the sixth (aka pass, fs_passno ) fields of /etc/fstab for ReiserFS filesystems? A: 0 0 Das sechste Feld ist fuer fsck zustaendig: steht dort eine Null, so wird das Filesystem nicht gecheckt. Wie Du siehst, soll das bei ReiserFS genau so sein. Das Log wird natuerlich trotzdem gecheckt und gegebenenfalls zurueckgespielt.
Deshalb hatte ich meine Sorge wegen der "Skipping fsck because root partition is read-write" (oder so) Meldung. Ich schloß daraus, dass das Journal jetzt überhaupt nicht mehr hergestellt wird.
Vermutlich hast Du in der /etc/fstab keine "0" im sechsten Feld, siehe oben.
Als ich in meinen letzten Postings denn Ausdruck "fsck" verwendete meinte ich immer das "Ueberpruefen des Log-Files mit evtl. anschliessender Korrektur am Filesystem". Genau das soll mein reiserfs nach einem Crash machen. Und zwar gut und schnell und ohne 400 Fehlermeldungen bei 20 - 30 Minuten Dauer. Sollten danach (nach dem Booten nach dem Crash) noch Fehler auf dem System vorhanden sein, die ich mit einem manuellen kompletten fsck der gesamten Platte beheben muß/soll, dann will ich _eine_ entsprechende Meldung.
Wieder aus der FAQ: o Q: Can I interactively repair a filesystem that was corrupted (due to an internal bug in the kernel or a to hardware fault)? A: man reiserfsck und o Q: Does using ReiserFS mean I can just press the power off button without running "shutdown" or "init 0," etc? Does it mean there is no risk of data loss? A: No, definitely not. As of now, ReiserFS only provides meta-data journaling-- that is, it records which files have been created or opened, whether they have had their size changed, or where they have been relocated. It guarantees that the structure of the internal ReiserFS tree will be correct, thereby allowing you after an unclean shutdown to start back up without having to run fsck on all the files that have not been changed. Data in files that were being used at the time of the crash could have been corrupted. This is usual for most filesystems. Data journaling filesystems guarantee that there will be no garbage written into a file, but they don't guarantee that a file update will be. (Only reiser4 guarantees that filesystem operations are performed as atomic operations, and provides atomic transaction functionality.) ReiserFS V3 does not guarantee the file contents themselves are uncorrupted nor that no data is lost. Moreover, even given that all of your system is on ReiserFS, many system components (like daemons, database managers, etc) require the shut down procedure for proper functioning. Nur weil Du also ReiserFS einsetzt, heisst das noch nicht, dass bei einem Crash alle Dateien genau so hinterlassen werden, wie Du es urspruenglich vorgesehen hast und gerne haben moechtest. Es kann immer noch Schrott in einer Datei stehen.... Jour- naling Filesysteme sind kein Allheilmittel :-) Gruesse, Th. -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
participants (3)
-
Martin Scharrer -
Thomas Hertweck -
Torsten Weckmann