Zustand vom Raid1 nicht ganz klar

Knappe · 1 Apr. 2009

Hallo,

Titel dieses Threads hört sich vielleicht merkwürdig an ... aber das Raid sieht auch so aus.
Hatte mir selbst die zweite Platte des Raid1´s "zerschossen" (nicht nachfragen wie... es ist so) und daher zunächst das Raid nur mit einer Platte am Laufen.

Gestern nun die zweite Platte formatiert (XFS, da nicht mehr mountbar) und mit

Code:

# mdadm /dev/md0 -a /dev/sdb1

reingehängt.
Anschliessend hat mdadm automatisch angefangen zu syncronisieren.

Nach 10 Stunden dann :

Ausgabe von

# cat /proc/mdadm

Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md0 : active raid1 sdb1[2] sda1[0]
976759864 blocks super 1.0 [2/2] [UU]
bitmap: 11/466 pages [44KB], 1024KB chunk

unused devices: <none>

Sieht gut aus ...

Dann Ausgabe von

# mdadm --detail /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Thu Nov 13 14:24:12 2008
Raid Level : raid1
Array Size : 976759864 (931.51 GiB 1000.20 GB)
Used Dev Size : 1953519728 (1863.02 GiB 2000.40 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Wed Apr 1 09:33:01 2009
State : active
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Name : 0
UUID : 87477f89:6bb19b23:9bbe7e7b:f9587d87
Events : 451210

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
2 8 17 1 active sync /dev/sdb1

Sieht doch auch noch gut aus ...

Aber jetzt

# mdadm --examine /dev/sda1 /dev/sdb1
/dev/sda1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : 87477f89:6bb19b23:9bbe7e7b:f9587d87
Name : 0
Creation Time : Thu Nov 13 14:24:12 2008
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1953519728 (931.51 GiB 1000.20 GB)
Array Size : 1953519728 (931.51 GiB 1000.20 GB)
Super Offset : 1953519984 sectors
State : clean
Device UUID : a7247a6b:06393ffc:a9ce580e:956b980d

Internal Bitmap : -234 sectors from superblock
Update Time : Wed Apr 1 09:48:45 2009
Checksum : cd312bfc - correct
Events : 451210

Array Slot : 0 (0, failed, 1)
Array State : Uu 1 failed

/dev/sdb1:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x1
Array UUID : 87477f89:6bb19b23:9bbe7e7b:f9587d87
Name : 0
Creation Time : Thu Nov 13 14:24:12 2008
Raid Level : raid1
Raid Devices : 2

Avail Dev Size : 1953519728 (931.51 GiB 1000.20 GB)
Array Size : 1953519728 (931.51 GiB 1000.20 GB)
Super Offset : 1953519984 sectors
State : active
Device UUID : 782abdb8:a10713e0:36aeb100:01309a5a

Internal Bitmap : -234 sectors from superblock
Update Time : Wed Apr 1 09:48:46 2009
Checksum : 3da2a45e - correct
Events : 451211

Array Slot : 2 (0, failed, 1)
Array State : uU 1 failed

Sieht aber gar nicht mehr gut aus ...

Einträge in der

/etc/mdadm.conf
DEVICE partitions
ARRAY /dev/md0 level=raid1 UUID=87477f89:6bb19b23:9bbe7e7b:f9587d87
MAILADDR xxxxx@xxxxxxx

Was ist da schiefgelaufen ?
Warum ist die Anzahl die "Events" so hoch (physische Defekte kann ich ausschliessen) und warum kommen die Fehlermeldungen bzgl. der Slots ?

Bin für Tipps & Hinweise dankbar und liefere bei Bedarf gerne noch weitere Infos.

josef-wien · 1 Apr. 2009

Interessant. Mit --examine habe ich mich bisher nicht beschäftigt. Bei mir sieht es so aus:

Code:

        Events : 256
    Array Slot : 1 (failed, 1, 0)
   Array State : uU 1 failed

        Events : 256
    Array Slot : 2 (failed, 1, 0)
   Array State : Uu 1 failed

(bzw. 270 Events beim anderen RAID1). Beide funktionieren seit Monaten einwandfrei.

Die Events könnten vielleicht mit der Synchronisierung zu tun haben, da ich damals (und auch bei einer Wiederherstellung nach einer eigenhändig beschädigten Partitionentabelle) 2 weitgehend identische Partitionen zusammengehängt habe, während Du eine leere Partition dazugehängt hast. Warten wir, was robi meint.

Anonymous · 1 Apr. 2009

Knappe schrieb:
md0 : active raid1 sdb1[2] sda1[0]
976759864 blocks super 1.0 [2/2] [UU]
bitmap: 11/466 pages [44KB], 1024KB chunk

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
2 8 17 1 active sync /dev/sdb1

Array Slot : 2 (0, failed, 1)
Array State : uU 1 failed

Ich vermute mal, hier hat sich die Raidkonfigurationen wahrscheinlich gemerkt, dass das Raid mal mit einer anderen Platte im Raid verheiratet war. Eventuell wurde sie getauscht oder war failed und ist dann wieder neu dazu gefügt worden, aber es wurde vergessen sie mit -r aus der Konfiguration heraus zu nehmen. Es sind 2 Device da, 0 und 2 das Device 1 fehlt.

Vom Prinzip ist das ein jetzt ein Schönheitsfehler, der keine negativen Auswirkungen auf die Raidfunktion haben sollte.

robi

Knappe · 1 Apr. 2009

Hallo @robi,

.., aber es wurde vergessen sie mit -r aus der Konfiguration heraus zu nehmen.

das stimmt.
Aber es wurde nicht vergessen: der Server lies sich überhaupt nicht mehr booten.
Auch "xfs_repair" unter Knoppix hat nichts mehr geholfen. Ich mußte die Platte physisch trennen.
Von dem Moment an hatte "mdadm" auch schon "failed" angezeigt.

Der Befehl

Code:

# mdadm /dev/md0 -r /dev/sdb1

funktionierte auch nicht.

Aber auch ein direktes Einbinden war nicht möglich. Daher mußte ich auch die Platte neu formatieren.

Es sind 2 Device da, 0 und 2 das Device 1 fehlt.

Genau. Bevor ich aber die o.g. Platte (wieder) reingehängt hatte, wurde die im Raid noch laufende Platte als "/dev/sdb1" geführt.
Nun da die andere Platte Bestandteil geworden ist, ist aus der "alten" dann /dev/sda1 geworden und die frisch formatierte /dev/sdb1.

Vom Prinzip ist das ein jetzt ein Schönheitsfehler, der keine negativen Auswirkungen auf die Raidfunktion haben sollte.

Hmm, da bin ich mir eben nicht so sicher.

Erstens finde ich die hohe Anzahl an Events merkwürdig (ein anderes RAID1 in diesem Server hat hierfür den Wert "0.21508")
Zweitens fand ich die Syncronisierungszeit von 10 Stunden sehr hoch (ich hatte den Eindruck, dass Teile immer wieder neu syncronisiert wurden, denn eigentlich hätte der Lauf bei 50 MB/Sek in rund 6 Stunden erledigt sein müssen).

...hier hat sich die Raidkonfigurationen wahrscheinlich gemerkt...

Wo könnte sich das Raid denn solche Infos merken ?
Ich könnte mir doch dann mal die Infos mit "dd" auslesen.

Zu einer möglichen Raid-Korrektur :
1. "neue" Platte mit "mdadm "/dev/md0 -r /dev/sdb1" herauslösen (oder erst -f, dann -r)
2. mit examine das dann bestehende Raid ansehen.
Eigentlich müßte hier die Info kommen, welches Device vermisst wird.
Dieses dann "faulty" setzen und anschliessend aus dem Raid nehmen.
3. "neue" Platte mit "mdadm /dev/md0 -a /dev/sdb1" neu hereinnehmen
4. "/etc/mdadm.conf" & "/etc/fstab" prüfen und anschliessen neu booten.

?

Anonymous · 1 Apr. 2009

Keine Ahnung was ihr für Versionen habt. Die Ausgaben von --examine die ich kenne, sehen etwas anders aus, aber das ist zwischen verschiedenen Versionen und Raidtypen normal. Ihr habt wahrscheinlich wieder 11.x
Kann das jetzt derzeitig auch überhaupt nicht testen, da ich derzeit auf nicht Linux-Software unterwegs bin.

Schaut mal in die Manpage, und versucht ein paar Optionen , --verbose --scan oder irgend sowas, irgendwo muss das im Superblock von der Platte ausführlicher zu sehen sein, also nicht aus /proc/mdstat sondern von Platte auslesen

Prinzipell hat jeder Raidsuperblock eine Device-UUID und die anderen Raidblöcke zum selben Raid kennen diese Device-IDs von den Partnerdevices. Wenn das Raid neu aufgesetzt wird, gibt es dann auch gleich wieder eine neue Device-UUID. Wird die Platte nicht sauber aus der Konfiguration entfernt, dann kennen die andere Platten dann aber die alte und die neue Device-UUID von dieser Platte/Partition und das ist wahrscheinlich genau passiert.

Wenn also irgendwer sich was gemerkt hat, dann kann das auch die Platte sein, die sich nicht geändert hat, die also die ganze Zeit online war. Da könnte diese ID noch als "vermisst" vom altem Raid im Superblock stehen.

Zu der Geschwindigkeit und den Events kann man so nichts sagen. das müsste man sich wohl genauer ansehen, was das für Events sind und was die Platte theoretisch und praktisch an Geschwindigkeiten bedienen kann und wieviel Prozent das Raid für seinen Rebuild nutzt.

robi

Zustand vom Raid1 nicht ganz klar

Knappe

Hacker

josef-wien

Ultimate Guru

Anonymous

Gast

Knappe

Hacker

Anonymous

Gast