Soft Raid5 - Platte wird nicht mehr eingebunden
Hallo Liste,
Ich habe hier ein Software Raid 5 am laufen, zumindest bis heute.
Aufbau:
3 Platten mit je 40 GB - hdb1,hdc1,hde1
Reihenfolge in Configfile wie oben angegeben.
keine spare disks
Ich habe heute einen Totalausfall(haenger des Systems) und musste
einen harten Reset machen(liess sich leider nicht vermeiden).
Seitdem laeuft das Raid nur noch mit hdb und hdc, hde wird nicht
mehr eingebunden.
Logischer weise habe ich nun auch keine Zugriff darauf.
Meldung in /var/log/messages:
linux kernel: (read) hdb1's sb offset: 39086016
[events: 0000003e]
Oct 28 19:37:00 linux kernel: (read) hdc1's sb offset: 39088576
[events: 0000003e]
Oct 28 19:37:00 linux kernel: autorun ...
Oct 28 19:37:00 linux kernel: considering hdc1 ...
Oct 28 19:37:00 linux kernel: adding hdc1 ...
Oct 28 19:37:00 linux kernel: adding hdb1 ...
Oct 28 19:37:00 linux kernel: created md0
Oct 28 19:37:00 linux kernel: bind
* Alexander Fieger schrieb am 28.10.01 um 19:44 Uhr:
Hallo Liste,
Ich habe hier ein Software Raid 5 am laufen, zumindest bis heute. Aufbau: 3 Platten mit je 40 GB - hdb1,hdc1,hde1 Reihenfolge in Configfile wie oben angegeben. keine spare disks Ich habe heute einen Totalausfall(haenger des Systems) und musste einen harten Reset machen(liess sich leider nicht vermeiden). Seitdem laeuft das Raid nur noch mit hdb und hdc, hde wird nicht mehr eingebunden. Logischer weise habe ich nun auch keine Zugriff darauf. Meldung in /var/log/messages:
[ kernel raid messages ]
Die Platte hde1 is ansprechbar und aktiv. Leider muss ich zugeben, dass ich keine Ahnung habe, wie ich das Dateisystem(ext2) ueberpruefen kann. Jedoch ist die Platte in Ordnung doch wird einfach nicht mehr eingebunden. Ich habe schon das HOWTO in Englisch und Deutsch mehrmals duchgelesen und div. andere Quellen besucht, jedoch ohne Ergebniss.
Hallo Alexander, hast du mal raidhotadd ausprobiert? Das gehoert IIRC zu den Raidtools dazu. Damit kannst du dem Kernel sagen, dass er die Platte wieder einbinden soll. Was sagt denn ueberhaupt ein # cat /proc/mdstat (Bin mir nicht ganz sicher, ob es so hies, jedenfalls stehen in einem File unter /proc Infos zum SoftRAID status. Muss evtl auch in den Kernel eincompiliert sein... Gruss -Marc -- +------------------------------------------------------------------+ | --> http://www.links2linux.de <-- Jetzt mit neuen Features! | | wie z.B. [EasyLink] | +---Registered-Linux-User-#136487------------http://counter.li.org +
Marc Schiffbauer schrieb am Sun, 28 Oct 2001 at 19:11 +0100:
* Alexander Fieger schrieb am 28.10.01 um 19:44 Uhr:
Hallo Liste,
Ich habe hier ein Software Raid 5 am laufen, zumindest bis heute. Aufbau: 3 Platten mit je 40 GB - hdb1,hdc1,hde1 Reihenfolge in Configfile wie oben angegeben. keine spare disks Ich habe heute einen Totalausfall(haenger des Systems) und musste einen harten Reset machen(liess sich leider nicht vermeiden). Seitdem laeuft das Raid nur noch mit hdb und hdc, hde wird nicht mehr eingebunden. Logischer weise habe ich nun auch keine Zugriff darauf. Meldung in /var/log/messages:
[ kernel raid messages ]
Die Platte hde1 is ansprechbar und aktiv. Leider muss ich zugeben, dass ich keine Ahnung habe, wie ich das Dateisystem(ext2) ueberpruefen kann. Jedoch ist die Platte in Ordnung doch wird einfach nicht mehr eingebunden. Ich habe schon das HOWTO in Englisch und Deutsch mehrmals duchgelesen und div. andere Quellen besucht, jedoch ohne Ergebniss.
Hallo Alexander,
hast du mal
raidhotadd
ausprobiert?
Ja, also, ich habe vor ca.10 Min bei der FAQ von der Raid Mailingliste etwas gefunden, das ebenfalls auf das raidhostadd verweisst. Dies habe ich natuerlich sofort ausprobiert und im Moment laeuft es auch.
Das gehoert IIRC zu den Raidtools dazu. Damit kannst du dem Kernel sagen, dass er die Platte wieder einbinden soll.
Was sagt denn ueberhaupt ein # cat /proc/mdstat
Im Moment, dass recovery laeuft und noch 592 min braucht(O Gott). Ich hoffe, dass es nach dem recovery wieder funktioniert. Im Moment kann ich jedenfalls das Array nicht mounten. Mount meldet: mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems Naja, ich warte mal bis recovery fertig ist und dann schauen mir mal.
(Bin mir nicht ganz sicher, ob es so hies, jedenfalls stehen in einem File unter /proc Infos zum SoftRAID status. Muss evtl auch in den Kernel eincompiliert sein...
Gruss -Marc
Alexander -- Alles geht, mann muss nur wissen wie!!!! Alexander Fieger | mailto:alex.fieger@keule4u.de
* Alexander Fieger schrieb am 28.10.01 um 20:28 Uhr:
Ja, also, ich habe vor ca.10 Min bei der FAQ von der Raid Mailingliste etwas gefunden, das ebenfalls auf das raidhostadd verweisst. Dies habe ich natuerlich sofort ausprobiert und im Moment laeuft es auch.
Was heisst das, es laeuft? Unten schreibst du ja, dass du es nicht mounten kannst.
Das gehoert IIRC zu den Raidtools dazu. Damit kannst du dem Kernel sagen, dass er die Platte wieder einbinden soll.
Was sagt denn ueberhaupt ein # cat /proc/mdstat Im Moment, dass recovery laeuft und noch 592 min braucht(O Gott).
das kann man auch beschleunigen, indem man die Parameter in proc veraendert. Jedenfalls ist das bei einem Raid1 der Fall, dass ja sofort nach dem Erstellen einsatzfaehig (wenn auch noch nicht redundant) ist. Deshalb wird der (re)build extra gebremst, um mit dem device auch arbeiten zu koennen. Wenn du es aber eben nicht brauchst, dann kann man die Transferrate erhoehen. Wieviel durchsatz zur Zeit eingestellt ist kann man ja auch in /proc irgendwo auslesen.
Ich hoffe, dass es nach dem recovery wieder funktioniert. Im Moment kann ich jedenfalls das Array nicht mounten. Mount meldet: mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems
Naja, ich warte mal bis recovery fertig ist und dann schauen mir mal.
Hm. Also bei Raid5 weiss ich jetzt nicht wie sich das verhaelt. Bei einer Spiegelung waere das jedenfalls kein gutes Zeichen, um es mal vorsichtig auszudruecken... Gruss -Marc -- BUGS My programs never have bugs. They just develop random features. If you discover such a feature and you want it to be removed: please send an email to bug@links2linux.de
Marc Schiffbauer schrieb am Sun, 28 Oct 2001 at 19:53 +0100:
verweisst. Dies habe ich natuerlich sofort ausprobiert und im Moment laeuft es auch.
Was heisst das, es laeuft? Unten schreibst du ja, dass du es nicht mounten kannst.
Damit meine ich nur das das recovery laeuft, und das ist schon sehr viel mehr als in den letzten 6-7 Std.
Was sagt denn ueberhaupt ein # cat /proc/mdstat Im Moment, dass recovery laeuft und noch 592 min braucht(O Gott).
das kann man auch beschleunigen, indem man die Parameter in proc veraendert. Jedenfalls ist das bei einem Raid1 der Fall, dass ja sofort nach dem Erstellen einsatzfaehig (wenn auch noch nicht redundant) ist. Deshalb wird der (re)build extra gebremst, um mit dem device auch arbeiten zu koennen. Wenn du es aber eben nicht brauchst, dann kann man die Transferrate erhoehen. Wieviel durchsatz zur Zeit eingestellt ist kann man ja auch in /proc irgendwo auslesen.
Damit kenne ich mich, um es milde auszudruecken, ueberhaupt nicht aus.
Ich hoffe, dass es nach dem recovery wieder funktioniert. Im Moment kann ich jedenfalls das Array nicht mounten. Mount meldet: mount: wrong fs type, bad option, bad superblock on /dev/md0, or too many mounted file systems
Naja, ich warte mal bis recovery fertig ist und dann schauen mir mal.
Hm. Also bei Raid5 weiss ich jetzt nicht wie sich das verhaelt. Bei einer Spiegelung waere das jedenfalls kein gutes Zeichen, um es mal vorsichtig auszudruecken...
Mach mir bitte keine Angst ! Wenn ich versuche zu mounten, dann kommt auser der Meldung die ich oben schon angegeben habe noch in der Messages: Oct 28 21:05:59 linux kernel: EXT2-fs error (device md(9,0)): ext2_check_descriptors: Block bitmap for group 260 not in group (block 0)! Oct 28 21:05:59 linux kernel: EXT2-fs: group descriptors corrupted ! Leider kann ich mit der Meldung ja ueberhaupt nichts anfangen. Ach ja, gerade eben kam noch diese Meldung in der warn: Oct 28 20:16:32 linux kernel: set_blocksize: b_count 1, dev md(9,0), block 46782, from c014f167 Oct 28 20:16:32 linux kernel: set_blocksize: b_count 1, dev md(9,0), block 46783, from c014f167 Oct 28 20:16:32 linux kernel: BAD WRITE 46720> Oct 28 20:16:32 linux kernel: md0: write error while reconstructing, at block 46720(4096). wobei die ersten beiden Zeilen sehr oft kamen. Angesichts dieser Tatsachen muss ich dir leider mit dem 'kein gutes Zeichen' zustimmen.
Gruss -Marc
Stossgebete zum Himmel schickender Alexander -- Alles geht, mann muss nur wissen wie!!!! Alexander Fieger | mailto:alex.fieger@keule4u.de
participants (2)
-
Alexander Fieger
-
Marc Schiffbauer