Superblock von FS wieder herstellen (RAID5 wieder aktiv)
Hallo zusammen, ich habe mein RAID wieder aktiviert bekommen. Allerding scheint auch der Superblock des Filesystemes etwas abbekommen zu haben. Das RAID (/dev/md0) ist aktiv und syncron. Wenn ich jedoch versuche es zu mounten bekomme ich die Meld mount: wrong fs type, bad option, bad superblock on /dev/md0, or to many mounted file systems Das Dateisystem ist XFS. Wie kann ich den Superblock wieder herstellen? Genau dieser scheint kaputt zu sein. Normalerweise kann ich mit 'file -sL /dev/xxx' den FS-Type ermitteln. Wenn ich diesen Befehl jedoch auf md0 anwende erhalte ich lediglich: /dev/md0: data Wobei 'data' der Mountpoint ist unter welchem das RAID füher eingehängt war. Ich habe schon versucht: xfs_check /dev/md0 auszuführen was jedoch nur zu: xfs_check: unexpected XFS SB magic number 0x494e41ed xfs_check: read faild: Invalid argument xfs_check: data size check failt xfs_check: cannot read root inode (22) bad superblock magic number 0x494e41ed, giving up Wie kann ich den Superblock wieder herstellen? Viele Grüße Sven
On 2005-03-29 15:58:57 +0200, Sven Gehr wrote:
Wie kann ich den Superblock wieder herstellen?
man xfs_repair Versuch's aber erstmal mit xfs_repair -n Gruß Martin -- http://www.tm.oneiros.de
Am Di 29.03.2005 16:25 schrieb Martin Schröder <martin@oneiros.de>:
On 2005-03-29 15:58:57 +0200, Sven Gehr wrote:
Hallo,
Wie kann ich den Superblock wieder herstellen?
man xfs_repair
Versuch's aber erstmal mit xfs_repair -n
ok, der repair läuft. Das heist es laufen die Ganze Zeit ................................... durch den Screen. Ab und zu kommt dann mal ................................ found candidate secondary superblock ................ unable to verify superblock, continuing......... Wie lange wird so etwas dauern bei einem RAID5 mit 3 x 68GB ? Hat jemand Erfahrung mit dem Tool? Viele Grüße Sven
On 2005-03-29 16:40:12 +0200, Sven Gehr wrote:
Wie lange wird so etwas dauern bei einem RAID5 mit 3 x 68GB ? Hat jemand Erfahrung mit dem Tool?
Bisher nicht. :-) Du hast ein Backup? Ansonsten: http://oss.sgi.com/projects/xfs/faq.html Gruß Martin -- http://www.tm.oneiros.de
Am Di 29.03.2005 16:44 schrieb Martin Schröder <martin@oneiros.de>:
On 2005-03-29 16:40:12 +0200, Sven Gehr wrote:
Hallo,
Wie lange wird so etwas dauern bei einem RAID5 mit 3 x 68GB ? Hat jemand Erfahrung mit dem Tool?
Bisher nicht. :-) Du hast ein Backup?
Muß ich die Frage beantworten? Nein, hab ich nicht.
Ansonsten: http://oss.sgi.com/projects/xfs/faq.html
Die FAQ habe ich mir mal angesehen, da steht aber nix über die XFS-Tools (xfs_check, xfs_repair etc.) drin. Ich habe mir die Manpage von xfs_repair mal durchgelesen. Mir erscheint die Option -o ein Versuch wert zu sein. Verstehe ich das richtig das er damit den Superblock aufgrund der Daten neu erzeugt? Viele Grüße Sven
On 2005-03-29 17:08:31 +0200, Sven Gehr wrote:
Am Di 29.03.2005 16:44 schrieb Martin Schröder <martin@oneiros.de>:
Bisher nicht. :-) Du hast ein Backup?
Muß ich die Frage beantworten? Nein, hab ich nicht.
Dann mach _jetzt_ eins: Besorg Dir eine ausreichend große Festplatte und sicher die Daten mit dd.
Ansonsten: http://oss.sgi.com/projects/xfs/faq.html
Die FAQ habe ich mir mal angesehen, da steht aber nix über die XFS-Tools (xfs_check, xfs_repair etc.) drin.
Ich habe mir die Manpage von xfs_repair mal durchgelesen. Mir erscheint die Option -o ein Versuch wert zu sein. Verstehe ich das richtig das er damit den Superblock aufgrund der Daten neu erzeugt?
Keine Ahnung. Versuch's mal auf der linux-xfs Mailingliste: Da erreichst Du direkt die Entwickler von SGI. Gruß Martin -- http://www.tm.oneiros.de
Am Di 29.03.2005 17:18 schrieb Martin Schröder <martin@oneiros.de>:
On 2005-03-29 17:08:31 +0200, Sven Gehr wrote:
Am Di 29.03.2005 16:44 schrieb Martin Schröder <martin@oneiros.de>:
Hallo,
Dann mach _jetzt_ eins: Besorg Dir eine ausreichend große Festplatte und sicher die Daten mit dd.
ok, ich habe mir mal auf die Schnelle die Beschreibung von dd durchgelesen. Sorry, wenn ich jetzt zur Sicherheit nochmal nachfrage. Reicht es wenn eine entsprechend große Partition vorhanden ist? Ich habe ein Partition die groß genug ist (hda3) mit XFS formatiert und nach /save eingehängt. Wenn ich das richtig verstehe muß ich jetzt die Partition aushängen und: dd if=/dev/md0 of=/dev/hda3 machen. Ist es dabei egal das hda3 größer ist als md0 ? Dann gibt es noch die Option bs=... welcher die Blockgröße angibt was auf einen Rutsch kopiert wird. Leider steht dabei kein sinnvolles Beispiel. Ich denke mal das sich diese Option maßgeblich auf die Geschwindigkeit dieser Aktion auswirkt. Was ist hier ein sinvoller Wert? Viele Grüße Sven
Ansonsten: http://oss.sgi.com/projects/xfs/faq.html
Die FAQ habe ich mir mal angesehen, da steht aber nix über die XFS-Tools (xfs_check, xfs_repair etc.) drin.
Ich habe mir die Manpage von xfs_repair mal durchgelesen. Mir erscheint die Option -o ein Versuch wert zu sein. Verstehe ich das richtig das er damit den Superblock aufgrund der Daten neu erzeugt?
Keine Ahnung. Versuch's mal auf der linux-xfs Mailingliste: Da erreichst Du direkt die Entwickler von SGI.
Gruß Martin -- http://www.tm.oneiros.de
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
On 2005-03-29 17:41:28 +0200, Sven Gehr wrote:
Am Di 29.03.2005 17:18 schrieb Martin Schröder <martin@oneiros.de>:
Dann mach _jetzt_ eins: Besorg Dir eine ausreichend große Festplatte und sicher die Daten mit dd.
ok, ich habe mir mal auf die Schnelle die Beschreibung von dd durchgelesen. Sorry, wenn ich jetzt zur Sicherheit nochmal nachfrage. Reicht es wenn eine entsprechend große Partition vorhanden ist? Ich habe ein Partition die groß genug ist (hda3) mit XFS formatiert und nach /save eingehängt. Wenn ich das richtig verstehe muß ich jetzt die Partition aushängen und:
dd if=/dev/md0 of=/dev/hda3
machen. Ist es dabei egal das hda3 größer ist als md0 ? Dann gibt es
Du kannst als of auch eine Datei angeben, dann ist das bestimmt kein Problem. :-)
noch die Option bs=... welcher die Blockgröße angibt was auf einen Rutsch kopiert wird. Leider steht dabei kein sinnvolles Beispiel. Ich denke mal das sich diese Option maßgeblich auf die Geschwindigkeit dieser Aktion auswirkt. Was ist hier ein sinvoller Wert?
Wahrscheinlich ein Vielfaches der bs Deiner xfs-Partitionen; normalerweise werden das 4K sein. Sicherheitshalber würde ich's weglassen. dd if=/dev/md0 of=/save/md0_sicherung.fs Danach: http://suse-linux-faq.koehntopp.de/q/q-filesystems-mount_image.html Gruß Martin -- http://www.tm.oneiros.de
Am Di 29.03.2005 17:50 schrieb Martin Schröder <martin@oneiros.de>:
On 2005-03-29 17:41:28 +0200, Sven Gehr wrote:
Am Di 29.03.2005 17:18 schrieb Martin Schröder <martin@oneiros.de>:
Hallo, [...]
ok, ich habe mir mal auf die Schnelle die Beschreibung von dd durchgelesen. Sorry, wenn ich jetzt zur Sicherheit nochmal nachfrage. Reicht es wenn eine entsprechend große Partition vorhanden ist? Ich habe ein Partition die groß genug ist (hda3) mit XFS formatiert und nach /save eingehängt. Wenn ich das richtig verstehe muß ich jetzt die Partition aushängen und:
dd if=/dev/md0 of=/dev/hda3 machen. Ist es dabei egal das hda3 größer ist als md0 ? Dann gibt es Du kannst als of auch eine Datei angeben, dann ist das bestimmt kein Problem. :-)
Ok, aber in der ML sprechen sie von einem Dump der Partition (mit dd) und anschließend soll ich das xfs_repair auf dieses Device anwenden. Das würde bei der Lösung "dd in File" ja nicht funktionieren, oder? Also wäre gut zu wissen ob dd sowohl bei if wie auch of ein Device akzeptiert.
noch die Option bs=... welcher die Blockgröße angibt was auf einen Rutsch kopiert wird. Leider steht dabei kein sinnvolles Beispiel. Ich denke mal das sich diese Option maßgeblich auf die Geschwindigkeit dieser Aktion auswirkt. Was ist hier ein sinvoller Wert? Wahrscheinlich ein Vielfaches der bs Deiner xfs-Partitionen; normalerweise werden das 4K sein.
ok, klar.
Sicherheitshalber würde ich's weglassen.
dd if=/dev/md0 of=/save/md0_sicherung.fs
In der Mailingliste habe ich gefunden: creating a new fs on another disk, using dd dump info from the other disk on the new disk... carefully offsetting, not to overwrite the superblock, and try xfs_repair on it .... but that wont work I guess Viele Grüße Sven
Hallo, Am Tue, 29 Mar 2005, Sven Gehr schrieb:
Am Di 29.03.2005 17:50 schrieb Martin Schröder <martin@oneiros.de>:
On 2005-03-29 17:41:28 +0200, Sven Gehr wrote:
Am Di 29.03.2005 17:18 schrieb Martin Schröder <martin@oneiros.de>: [..] dd if=/dev/md0 of=/dev/hda3 machen. Ist es dabei egal das hda3 größer ist als md0 ? Dann gibt es Du kannst als of auch eine Datei angeben, dann ist das bestimmt kein Problem. :-)
Ok, aber in der ML sprechen sie von einem Dump der Partition (mit dd) und anschließend soll ich das xfs_repair auf dieses Device anwenden. Das würde bei der Lösung "dd in File" ja nicht funktionieren, oder? Also wäre gut zu wissen ob dd sowohl bei if wie auch of ein Device akzeptiert.
Devices sind Dateien. 'dd' liest und schreibt (wie eigentlich alle unix-tools) generell nur in/aus Dateien. Default ist if=/dev/stdin und of=/dev/stdout sowie bs=512 (ein Festplatten-Sektor). Du kannst also z.B. 'dd if=/dev/zero of=/dev/null count=1' verwenden um Nullen ins Bit-Nirvana zu schieben, oder 'dd if=/das/ist/eine/normale/datei' statt 'cat /das/.../datei'. Oder oder oder. dd ist das alles egal ;) Die "Art" der Datei, also ob normal, blockdevice, pipe (stdin/-out) usw. wird mit dd erst dann relevant, wenn seek, skip und conv verwendet werden. Und in deinem Fall wuerde ich das Image von md0 als _DATEI_ auf /dev/hda3 ablegen. Also /dev/hda3 ggfs. noch formatieren, mounten (z.B. nach /mnt/hda3) und dann: dd if=/dev/md0 of=/mnt/hda3/md0.img bs=4k ^^^(hier nix dev ;) Auf das Image kannst du dann anschliessend die diversen Tools (und sei's ein hex-editor) auf das Image loslassen. Und das Image dann mounten, wenn die Reparatur klappt. Du bekommst aber evtl. ein "is not a block device" an den Kopf geworfen, davon braucht man sich aber nicht unbedingt irritieren lassen.
In der Mailingliste habe ich gefunden:
creating a new fs on another disk, using dd dump info from the other disk on the new disk... carefully offsetting, not to overwrite the superblock, and try xfs_repair on it .... but that wont work I guess
Das passt nicht wirklich zu deinem Fall, gemeint ist aber wohl seek= und skip= so zu waehlen, dass der SB des neuen FS nicht ueberschrieben wird, der Rest des FS aber mit den Daten des alten FS. Wie das funktionieren soll ist mir aber schleierhaft, ich kenne XFS zwar nicht, aber bei allen FSen die ich (naeher) kenne geht das nicht (FAT12, 16, 32, NTFS, ext2, ext3, reiserfs). Ich kann mir nicht vorstellen, dass das bei XFS geht. IMO also: BLOSS NICHT!!eins! -dnh --
Ach.Frisches Blut ist hier also nicht gern gesehen? Nur, wenn es von meiner Kettensaege tropft. [Erik Meltzer und Dieter Bruegmann in dag°]
Am Tue, 29 Mar 2005, Sven Gehr schrieb: Am Di 29.03.2005 22:28 schrieb David Haller <david@dhaller.de>:
Hallo, [...]
Devices sind Dateien. 'dd' liest und schreibt (wie eigentlich alle unix-tools) generell nur in/aus Dateien. Default ist if=/dev/stdin und of=/dev/stdout sowie bs=512 (ein Festplatten-Sektor).
[...]
Und in deinem Fall wuerde ich das Image von md0 als _DATEI_ auf /dev/hda3 ablegen. Also /dev/hda3 ggfs. noch formatieren, mounten (z.B. nach /mnt/hda3) und dann:
dd if=/dev/md0 of=/mnt/hda3/md0.img bs=4k ^^^(hier nix dev ;)
Das hatte ich vorhin schon mal gemacht. erwartungsgemäß das der xfs_repair auf das Image-File angewendet, auch keine Besserung gebracht. Ist eigentlich logisch, da es ja eine 1:1 - Kopie ist.
Auf das Image kannst du dann anschliessend die diversen Tools (und sei's ein hex-editor) auf das Image loslassen. Und das Image dann mounten, wenn die Reparatur klappt.
Ich denke genau hier liegt mein Problem. Ich weiß nicht wie ich es mit den XFS-Tools scahffe das Problem zu beseitigen. Alleine mit dem dump ist es ja nicht getan. Die Notwendigkeit des Dump's liegt wohl darin bei einem Wiederherstellungs-Versuch nicht die Orginal-Daten zu zerpflügen.
Du bekommst aber evtl. ein "is not a block device" an den Kopf geworfen, davon braucht man sich aber nicht unbedingt irritieren lassen.
Nö, da kam nix.
In der Mailingliste habe ich gefunden:
creating a new fs on another disk, using dd dump info from the other disk on the new disk... carefully offsetting, not to overwrite the superblock, and try xfs_repair on it .... but that wont work I guess
Das passt nicht wirklich zu deinem Fall, gemeint ist aber wohl seek= und skip= so zu waehlen, dass der SB des neuen FS nicht ueberschrieben wird, der Rest des FS aber mit den Daten des alten FS. Wie das funktionieren soll ist mir aber schleierhaft, ich kenne XFS zwar nicht, aber bei allen FSen die ich (naeher) kenne geht das nicht (FAT12, 16, 32, NTFS, ext2, ext3, reiserfs). Ich kann mir nicht vorstellen, dass das bei XFS geht.
dann vergess ich das am besten wieder. Ich fasse zusammen. Bei meinem XFS ist sobwohl der primäre wie auch der sekundäre SB im A.. äh kaputt. Also ist das was ich brauche, eine Möglichkeit diesen Superblock wieder herzustellen. Ich meine mich zu erinnern das ich von ca. 2 Jahren mal einen ähnlichen Crash eines ext3 hatte. Damals mußte ich einen, sehr intensieven Check des FS's, durchführen der auch ca. einen Tag gedauert hat. Kennt sich jemand mit XFS aus und weiß ob es dort eine Möglichkeit gibt?
IMO also: BLOSS NICHT!!eins!
??? Versteh ich jetzt nicht. **StehAufDemSchlauch* Viele Grüße Sven
Am Di 29.03.2005 16:40 schrieb Sven Gehr <sven@dreampixel.de>:
Am Di 29.03.2005 16:25 schrieb Martin Schröder <martin@oneiros.de>:
On 2005-03-29 15:58:57 +0200, Sven Gehr wrote:
Hallo,
Wie kann ich den Superblock wieder herstellen? man xfs_repair Versuch's aber erstmal mit xfs_repair -n ok, der repair läuft. Das heist es laufen die Ganze Zeit ................................... durch den Screen. Ab und zu kommt dann mal
................................ found candidate secondary superblock ................ unable to verify superblock, continuing.........
Wie lange wird so etwas dauern bei einem RAID5 mit 3 x 68GB ? Hat jemand Erfahrung mit dem Tool?
ok, der xfs_repair ist durch. Am Ende kam die Meldung: Sorry, could not find vailid secondary superblock. Exiting now. Was kann ich jetzt noch tun? Viele Grüße Sven
participants (3)
-
David Haller -
Martin Schröder -
Sven Gehr