RAID5 startet nicht mehr

Hallo Leute,

jetzt ist's passiert, nach dem letzten Schritt bei der Umstellung meines 11.0 Homeserver
startet das RAID5 nicht mehr.

Leitfaden hierzu waren die beiden Artikel der c't 1 und 2 2009.

Kurz zu meiner Systemumgebung. Im System sind nun 3 Platten (2x1TB und 1x750GB) auf dem
jetzt 1 256MB RAID1 (/dev/md0) als Boot-Partition und ein 1,5TB RAID5 (dev/md1) mit
drüberliegenden LVM liegt, in dem wiederum die Root, /var und /srv als separate Volumes
enthalten sind.

Das System lief prima und nur eine Sache wollte ich noch machen: Das RAID5 auf die
maximale Größe erweitern.

Nachdem der Befehl
mdadm /dev/md1 --grow --size=max
im laufenden System nicht wollte, habe ich KNOPPIX 5.3 gebootet und diese Operation da
ausgeführt. Das lief auch ohne Fehlermeldung durch, fdisk zeigte mir das /dev/md1 auch
mit der neuen Größe korrekt an. Das LVM lies sich auch in KNOPPIX starten und das
testweise mounten der Volumes klappte auch.
Nur der anschließende Start des eigentlichen Systems schlug fail, da das RAID5 und somit
auch das LVM nicht mehr gestartet werden konnte.

Habe dann nochmals KNOPPIX gebootet, da konnte ich das RAID5 auch nicht mehr korrekt
starten, das LVM startete mit Fehler aber die Volumes konnte ich noch sehen aber nicht
mehr mounten.

Habe dann das Rettungssystem der 11.1 gestartet, der kann natürlich auch nicht mehr das
RAID5 starten, wohingegen das RAID1 korrekt gestartet wird.

Beim Start kommt es hierbei zu folgenden (Fehler-)Meldungen:

# mdadm --assemble -v --force /dev/md1 /dev/sda2 /dev/sdb3 /dev/sdc3
mdadm: looking for devices for /dev/md1
mdadm: /dev/sda2 is identified as a member of /dev/md/1, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md/1, slot 2.
mdadm: /dev/sdc3 is identified as a member of /dev/md/1, slot 1.
mdadm: added /dev/sdc3 to /dev/md/1 as 1
mdadm: added /dev/sdb3 to /dev/md/1 as 2
mdadm: added /dev/sda2 to /dev/md/1 as 0
mdadm: failed to RUN_ARRAY /dev/md/1: Input/output error

In /var/log/messages steht dann
May 31 11:16:35 Rescue kernel: md: bind<sdc3>
May 31 11:16:35 Rescue kernel: md: bind<sdb3>
May 31 11:16:35 Rescue kernel: md: bind<sda2>
May 31 11:16:35 Rescue kernel: raid5: device sda2 operational as raid disk 0
May 31 11:16:35 Rescue kernel: raid5: device sdb3 operational as raid disk 2
May 31 11:16:35 Rescue kernel: raid5: device sdc3 operational as raid disk 1
May 31 11:16:35 Rescue kernel: raid5: allocated 3176kB for md1
May 31 11:16:35 Rescue kernel: raid5: raid level 5 set md1 active with 3 out of 3
devices, algorithm 0
May 31 11:16:35 Rescue kernel: RAID5 conf printout:
May 31 11:16:35 Rescue kernel: --- rd:3 wd:3
May 31 11:16:35 Rescue kernel: disk 0, o:1, dev:sda2
May 31 11:16:35 Rescue kernel: disk 1, o:1, dev:sdc3
May 31 11:16:35 Rescue kernel: disk 2, o:1, dev:sdb3
May 31 11:16:35 Rescue kernel: attempt to access beyond end of device
May 31 11:16:35 Rescue kernel: sda2: rw=8, want=1464613923, limit=1464613920
May 31 11:16:35 Rescue kernel: attempt to access beyond end of device
May 31 11:16:35 Rescue kernel: sdb3: rw=8, want=1464613923, limit=1464613920
May 31 11:16:35 Rescue kernel: attempt to access beyond end of device
May 31 11:16:35 Rescue kernel: sdc3: rw=8, want=1464613923, limit=1464613920
May 31 11:16:35 Rescue kernel: md1: bitmap initialisation failed: -5
May 31 11:16:35 Rescue kernel: md1: failed to create bitmap (-5)

Ein
# mdadm --detail /dev/md1 spuckt aus
/dev/md1:
Version : 1.00
Creation Time : Wed May 27 18:20:08 2009
Raid Level : raid5
Used Dev Size : 732306816 (698.38 GiB 749.88 GB)
Raid Devices : 3
Total Devices : 3
Persistence : Superblock is persistent

Update Time : Sat May 30 16:47:05 2009
State : active, Not Started
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-asymmetric
Chunk Size : 128K

Name : 1
UUID : b90c1a32:a7ceb166:2004618a:dc8b44cf
Events : 32502

Number Major Minor RaidDevice State
4 8 2 0 active sync /dev/sda2
5 8 35 1 active sync /dev/sdc3
3 8 19 2 active sync /dev/sdb3


Es erscheint mir offensichtlich, dass ewas mit dem Vergrößern nicht geklappt hat, da er
über das Ende hinaus zugreifen will.

Die Frage stellt sich jetzt, ist da noch etwas zu Reparieren? In Netz konnte ich bei
meiner Suche leider kein vergleichbares Fehlerszenario finden.

Weis jemand Rat?

Ich brauche ja wohl nicht zu erwähnen dass da eine Menge Daten drauf sind die ich
eigentlich wieder haben möchte. Zwar habe ich komplette Backups des Systems auf Band aber
halt nicht die wirklich großen Sachen wie Virtuelle Maschinen, Videos, iSCSI Laufwerke

Vielen Dank für Antworten schon im voraus

Gruß Manfred

ps
Euch allen frohe Pfingsten

mkreisl schrieb:

Nachdem der Befehl
mdadm /dev/md1 --grow --size=max
im laufenden System nicht wollte, habe ich KNOPPIX 5.3 gebootet und diese Operation da
ausgeführt. Das lief auch ohne Fehlermeldung durch, fdisk zeigte mir das /dev/md1 auch
mit der neuen Größe korrekt an. Das LVM lies sich auch in KNOPPIX starten und das
testweise mounten der Volumes klappte auch.
Nur der anschließende Start des eigentlichen Systems schlug fail, da das RAID5 und somit
auch das LVM nicht mehr gestartet werden konnte.

Zum Vergrößern anklicken....

zeig mal bitte die Ausgabe folgender Befehle
ich hab aus dieser Fehlerbeschreibung heraus eine ganz wage Vermutung, das der Kernel zum Zeitpunkt des growth nicht mit den jetzigen Partitionstabellen gearbeitet hat. Sowas könnte zB passiert wenn man so schlau ist und den MBR mit dd auf eine andere Platte überträgt und dem Kernel darüber nicht "Bescheid" gibt und immer schön ohne reboot weiter arbeitet und sich auf die Ausgabe von fdisk verläßt.


robi

Hallo robi,

hier sind die gewünschten Ausgaben. Hat etwas gedauert, bin wie du dir vorstellen kannst sehr gestresst

Avail Dev Size : 1464613648 (698.38 GiB 749.88 GB)
Array Size : 2929227264 (1396.76 GiB 1499.76 GB)
Used Dev Size : 1464613632 (698.38 GiB 749.88 GB)
Chunk Size : 128K
Avail Dev Size : 1464613648 (698.38 GiB 749.88 GB)
Array Size : 2929227264 (1396.76 GiB 1499.76 GB)
Used Dev Size : 1464613632 (698.38 GiB 749.88 GB)
Chunk Size : 128K
Avail Dev Size : 1464613648 (698.38 GiB 749.88 GB)
Array Size : 2929227264 (1396.76 GiB 1499.76 GB)
Used Dev Size : 1464613632 (698.38 GiB 749.88 GB)
Chunk Size : 128K

Disk /dev/sda: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sda1 * 63 530144 265041 fd Linux raid autodetect
/dev/sda2 530145 1465144064 732306960 fd Linux raid autodetect

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x000bd433

Device Boot Start End Blocks Id System
/dev/sdb1 * 63 530144 265041 fd Linux raid autodetect
/dev/sdb2 530145 3678884 1574370 82 Linux swap / Solaris
/dev/sdb3 3678885 1468292804 732306960 fd Linux raid autodetect
/dev/sdb4 1468292805 1953520064 242613630 83 Linux

Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00016ef1

Device Boot Start End Blocks Id System
/dev/sdc1 * 63 530144 265041 fd Linux raid autodetect
/dev/sdc2 530145 3678884 1574370 82 Linux swap / Solaris
/dev/sdc3 3678885 1468292804 732306960 fd Linux raid autodetect

Sieht für mich eigentlich recht passabel aus.

Also solche "Schweinereiten" mit dd etc habe ich nicht gemacht. Was ich gemacht hatte ist mach dem grow das System nicht neu gebootet, sondern gleich darauf das LVM gestartet.
Achja, ich vergaß, nach dem grow hab ich auch gleich noch ein pvresize /dev/md1 gemacht, das lief auch fehlerfrei durch.

Ich poste hier noch mal die gesamte Ausgabe von
dev/sda2:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : b90c1a32:a7ceb166:2004618a:dc8b44cf
Name : 1
Creation Time : Wed May 27 20:20:08 2009
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 1464613648 (698.38 GiB 749.88 GB)
Array Size : 2929227264 (1396.76 GiB 1499.76 GB)
Used Dev Size : 1464613632 (698.38 GiB 749.88 GB)
Super Offset : 1464613904 sectors
State : clean
Device UUID : c077e588:b89c3fa8:436d3569:5a9943b8

Internal Bitmap : -157 sectors from superblock
Update Time : Sat May 30 18:47:05 2009
Checksum : 8861f00a - correct
Events : 32502

Layout : left-asymmetric
Chunk Size : 128K

Array Slot : 4 (failed, failed, failed, 2, 0, 1)
Array State : Uuu 3 failed
/dev/sdb3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : b90c1a32:a7ceb166:2004618a:dc8b44cf
Name : 1
Creation Time : Wed May 27 20:20:08 2009
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 1464613648 (698.38 GiB 749.88 GB)
Array Size : 2929227264 (1396.76 GiB 1499.76 GB)
Used Dev Size : 1464613632 (698.38 GiB 749.88 GB)
Super Offset : 1464613904 sectors
State : clean
Device UUID : 5832cb0b:1770d97d:25bc8e49:2266abfa

Internal Bitmap : -157 sectors from superblock
Update Time : Sat May 30 18:47:05 2009
Checksum : 3a299aa - correct
Events : 32502

Layout : left-asymmetric
Chunk Size : 128K

Array Slot : 3 (failed, failed, failed, 2, 0, 1)
Array State : uuU 3 failed
/dev/sdc3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : b90c1a32:a7ceb166:2004618a:dc8b44cf
Name : 1
Creation Time : Wed May 27 20:20:08 2009
Raid Level : raid5
Raid Devices : 3

Avail Dev Size : 1464613648 (698.38 GiB 749.88 GB)
Array Size : 2929227264 (1396.76 GiB 1499.76 GB)
Used Dev Size : 1464613632 (698.38 GiB 749.88 GB)
Super Offset : 1464613904 sectors
State : clean
Device UUID : cc03184c:3328f80e:e4151216:0d81e6e5

Internal Bitmap : -157 sectors from superblock
Update Time : Sat May 30 18:47:05 2009
Checksum : 8ccc97e5 - correct
Events : 32502

Layout : left-asymmetric
Chunk Size : 128K

Array Slot : 5 (failed, failed, failed, 2, 0, 1)
Array State : uUu 3 failed


was mich da sehr stutzig macht ist folgende Zeile
Internal Bitmap : -157 sectors from superblock
Da kann doch wirklich was nicht stimmen, nur wie Reparieren, da bin ich völlig ratlos

Gruß Manfred

Also ich hab mal alles zusammen gerechnet und überschlagen, die size wurde wirklich auf "max" gesetzt. es passt aber meiner Rechnung nach alles, die einzelnen Raid-Teile sollten also in den Partitionen ok sein und 128KB Platz für den Superblock ist auch. Und es sind noch ein paar wenige Blöcke übrig, so das alles auf der Partition Platz haben sollte.
Trotzdem meldet irgendein IO-Treiber das deine Partitionen genau (3 x 512 Byte) größer sein müssten als sie wirklich sind. :???: :???: :???:

http://www.tuxmachines.org/node/35389
Also doch in irgendwelchen Metadaten Müll drin.
Entweder gleich aufs Backup gehen. Oder wenn du noch ein paar große Platten hast versuchen 2 Partitionen auf andere Platten in etwas größere Partitionen hineinzukopieren? Oder an der Partitionstabelle rumspielen? Eventuell hast du ja auch noch die ehemaligen Platten die vor der Vergrößerungsaktion gelaufen sind. Keine Ahnung was hier hilft, solche Fehler repariert man normalerweise mit Hilfe des Backup. Das geht am schnellsten.

robi

robi schrieb:

Also ich hab mal alles zusammen gerechnet und überschlagen, die size wurde wirklich auf "max" gesetzt. es passt aber meiner Rechnung nach alles, die einzelnen Raid-Teile sollten also in den Partitionen ok sein und 128KB Platz für den Superblock ist auch. Und es sind noch ein paar wenige Blöcke übrig, so das alles auf der Partition Platz haben sollte.
Trotzdem meldet irgendein IO-Treiber das deine Partitionen genau (3 x 512 Byte) größer sein müssten als sie wirklich sind. :???: :???: :???:

Zum Vergrößern anklicken....

Woran erkennst du denn das?

robi schrieb:

http://www.tuxmachines.org/node/35389
Also doch in irgendwelchen Metadaten Müll drin.
Entweder gleich aufs Backup gehen. Oder wenn du noch ein paar große Platten hast versuchen 2 Partitionen auf andere Platten in etwas größere Partitionen hineinzukopieren? Oder an der Partitionstabelle rumspielen? Eventuell hast du ja auch noch die ehemaligen Platten die vor der Vergrößerungsaktion gelaufen sind. Keine Ahnung was hier hilft, solche Fehler repariert man normalerweise mit Hilfe des Backup. Das geht am schnellsten.

Zum Vergrößern anklicken....

Platten hab ich leider keine mehr, hätt' ich welche wär ich wahrscheinlich gar nicht in diesem Dilemma

Ich hab heute vom Tape mein System wieder in einen noch freien Bereich der einen 1TB Platte installiert und es läuft wieder, aaaaaber meine eingangs erwähnten Daten (Virtuelle Maschinen, iSCSI Drives etc) sind halt weg und nicht wiederherstellbar.

Daher möcht ich halt nach wie vor versuchen, das RAID5 wieder herzustellen. Nur halt wie?

Leider bin ich (derzeit) alles andere als Experte in Sachen SW-Raid. Hab mich wohl von den c't Artikeln blenden lassen. Ich hab zwar das gesamte Szenario vorher in einer VM durchgespielt aber nur halt die grow Operation nicht.

Gruß Manfred

mkreisl schrieb:

Woran erkennst du denn das?

Zum Vergrößern anklicken....

/dev/sdb3 3678885 1468292804 732306960 fd Linux raid autodetect

Zum Vergrößern anklicken....

732306960 x 2 = 1464613920 (512er Blöcke)

May 31 11:16:35 Rescue kernel: sdb3: rw=8, want=1464613923, limit=1464613920

Zum Vergrößern anklicken....

1464613920 - 1464613923 = -3 (512er Blöcke) die eben scheinbar fehlen.

robi

Hallo robi,
so allmählich versteh' ich was du meinst. Das könnte wirklich der Grund sein. Ich schätze mal dass nicht 3 sondern 4 Blöcke fehlen, da ich mal davon ausgehe dass die Blöcke von 0 an gezählt werden, aber das tut nicht wirklich was zur Sache.

Was hälst du davon, einfach ein neues RAID5 auf den vorhandenen Partitionen anzulegen. Hab da beim googeln was darüber gelesen. Hab das in meiner Test-VM mal probiert und da hat es geklappt. Aber da war das RAID5 vorher auch schon in Ordnung

Gruß Manfred

mkreisl schrieb:

Was hälst du davon, einfach ein neues RAID5 auf den vorhandenen Partitionen anzulegen. Hab da beim googeln was darüber gelesen. Hab das in meiner Test-VM mal probiert und da hat es geklappt.

Zum Vergrößern anklicken....

Probieren kann man einiges, unter anderem auch das, nur musst du hier höllisch auf die richtige Reihenfolge achten bei Raid5.

Aber denke daran, solange du keinen Platz gefunden hast um die Partitionen wie sie sich jetzt darstellen alle 3 zu sichern.
ZB wie hier beschrieben http://www.linupedia.org/opensuse/Dd#Beispiel:_dd_nach_einem_Super-GAU_im_Filesystem
hast du genau eine einzige Chance, geht die Schief, sind die Daten entgültig flöten.
Bei 3 x 700GB wenig bis nicht komprimierbare Daten. brauchst du wahrscheilich LTO4 Bandlaufwerk und 3 Cartridges, oder mehrere weitere große Platten, wenn du das sichern willst.

robi