MDADM Raid5 Rebuild wird nicht korrekt durchgeführt

[Fubbel]

Hallo,

ich habe hier ein Ubuntu 8.04 welches von einer Single HDD bootet.

Desweiteren habe ich ein Software Raid 5 mit mdadm eingerichtet. 4x1TB von WD.

Voraus gingen so ein paar Sachen die ich hier kurz aufführen möchte.

Zuerst bestand das Raid aus 2 HDD's. Ein Raid 1 mit 2x1TB WD.
Ich habe 2 neue WD HDD's geholt und wollte nun ein Raid5 machen ohne meine Daten zu verlieren.
Wie hab ich das gemacht?
Ich habe das Raid1 degraded, sprich eine HDD entfernt.
Danach habe ich ein Raid5 aufgebaut. Mit 4 HDD's. Obwohl nur 3 verfügbar. Dies ging über den missing Eintrag. Sah dann etwa so aus.
mdadm --create level=5 --num-devices=4 /dev/sda1 missing /dev/sdc1 /dev/sdd1

Das hat auch alles geklappt, ich habe dann die Daten aus dem degraded Raid1 auf das Raid5 übertragen.
Danach die einzelne HDD erstmal formatiert Partition gelöscht, neu angelegt.
Soweit so gut.

Nun möchte ich die HDD in das Raid 5 hinzufügen. So das es nicht mehr degraded ist. Habe ich versucht mit
mdadm --add /dev/md1 /dev/sdb1
Dies startet einen Rebuild. Der eine Weile macht. Das Ende vom Lied ist das mein Raid nicht mehr ansprechbar ist. sdb1 und sda1 fliegen aus dem Array.
Mittels assemble kann ich mein bestehendes Raid5 mit 3 HDD's wieder zusammenführen und habe Zugriff auf die Daten.
Den Rebuild bzw. recovery Prozess habe ich bereits 3 mal ausprobiert.

Dachte dann an einen defekt einer HDD. Habe sda und sdb mit badblocks geprüft. Kein Fehler.

Hat jemand von euch Tipps? Wo liegt das Problem? Was mache ich falsch?

Etwas was mir aufgefallen ist und was mich stört, bzw. was ich komisch finde....

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[4] sda1[0] sdd1[3] sdc1[2]
      2930279808 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
      [>....................]  recovery =  2.0% (20379520/976759936) finish=243.1min speed=65540K/sec

sdb1 erhält die Nummer 4? Sollte ja eigentlich die 1 sein. sda1=0, sdc1=2, sdd1=3

Weiterhin sehr komisch ist....

mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90.03
  Creation Time : Fri May 29 19:59:21 2009
     Raid Level : raid5
     Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Tue Jun  2 23:04:35 2009
          State : clean, degraded, recovering
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

 Rebuild Status : 6% complete

           UUID : 42576807:3e3b7c9d:e368bf24:bd0fce41
         Events : 0.3274

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       4       8       17        1      spare rebuilding   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1

Warum wird sdb1 als Spare eingebunden?
Anfangs dachte ich naja wenn es beim Rebuild Spare ist und danach eine normale Array HDD ist mir das ja egal. Nur wird der Rebuild ja leider nicht beendet.

meine Config

cat /etc/mdadm/mdadm.conf
ARRAY /dev/md1 level=raid5 num-devices=4 UUID=42576807:3e3b7c9d:e368bf24:bd0fce41

syslog hat folgendes:

Jun  2 22:55:13 ubuntu kernel: [   37.614613] md: md1 stopped.
Jun  2 22:55:13 ubuntu kernel: [   37.617768] md: bind<sda1>
Jun  2 22:55:13 ubuntu kernel: [   37.628969] md: md1 stopped.
Jun  2 22:55:13 ubuntu kernel: [   37.628979] md: unbind<sda1>
Jun  2 22:55:13 ubuntu kernel: [   37.628983] md: export_rdev(sda1)
Jun  2 22:55:13 ubuntu kernel: [   37.631607] md: bind<sdc1>
Jun  2 22:55:13 ubuntu kernel: [   37.631757] md: bind<sda1>
Jun  2 22:55:13 ubuntu kernel: [   37.634601] md: md1 stopped.
Jun  2 22:55:13 ubuntu kernel: [   37.634611] md: unbind<sda1>
Jun  2 22:55:13 ubuntu kernel: [   37.634615] md: export_rdev(sda1)
Jun  2 22:55:13 ubuntu kernel: [   37.634623] md: unbind<sdc1>
Jun  2 22:55:13 ubuntu kernel: [   37.634625] md: export_rdev(sdc1)
Jun  2 22:55:13 ubuntu kernel: [   37.637413] md: bind<sdc1>
Jun  2 22:55:13 ubuntu kernel: [   37.637566] md: bind<sdd1>
Jun  2 22:55:13 ubuntu kernel: [   37.637700] md: bind<sda1>
Jun  2 22:55:13 ubuntu kernel: [   37.642451] raid5: allocated 4274kB for md1
Jun  2 22:55:13 ubuntu kernel: [   37.642453] raid5: raid level 5 set md1 active with 3 out of 4 devices, algorithm 2
Jun  2 22:57:25 ubuntu kernel: [  182.120310] EXT3 FS on md1, internal journal
Jun  2 22:57:39 ubuntu kernel: [  196.818404] EXT3 FS on md1, internal journal
Jun  2 22:59:49 ubuntu kernel: [  325.906571] md: bind<sdb1>
Jun  2 22:59:49 ubuntu kernel: [  326.376674] md: recovery of RAID array md1
Jun  2 22:59:49 ubuntu kernel: [  326.376677] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Jun  2 22:59:49 ubuntu kernel: [  326.376678] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Jun  2 22:59:49 ubuntu kernel: [  326.376681] md: using 128k window, over a total of 976759936 blocks.
Jun  2 23:00:21 ubuntu kernel: [  358.002375] md: md1: recovery done.
Jun  2 23:00:52 ubuntu kernel: [  388.845651] md: md1 stopped.
Jun  2 23:00:52 ubuntu kernel: [  388.845666] md: unbind<sdb1>
Jun  2 23:00:52 ubuntu kernel: [  388.845671] md: export_rdev(sdb1)
Jun  2 23:00:52 ubuntu kernel: [  388.845679] md: unbind<sda1>
Jun  2 23:00:52 ubuntu kernel: [  388.845682] md: export_rdev(sda1)
Jun  2 23:00:52 ubuntu kernel: [  388.845720] md: unbind<sdd1>
Jun  2 23:00:52 ubuntu kernel: [  388.845723] md: export_rdev(sdd1)
Jun  2 23:00:52 ubuntu kernel: [  388.845799] md: unbind<sdc1>
Jun  2 23:00:52 ubuntu kernel: [  388.845802] md: export_rdev(sdc1)
Jun  2 23:02:26 ubuntu kernel: [  483.633568] md: md1 stopped.
Jun  2 23:02:28 ubuntu kernel: [  485.513600] md: bind<sdc1>
Jun  2 23:02:28 ubuntu kernel: [  485.513764] md: bind<sdd1>
Jun  2 23:02:28 ubuntu kernel: [  485.513884] md: bind<sdb1>
Jun  2 23:02:28 ubuntu kernel: [  485.514003] md: bind<sda1>
Jun  2 23:02:28 ubuntu kernel: [  485.514032] md: kicking non-fresh sdb1 from array!
Jun  2 23:02:28 ubuntu kernel: [  485.514038] md: unbind<sdb1>
Jun  2 23:02:28 ubuntu kernel: [  485.514042] md: export_rdev(sdb1)
Jun  2 23:02:28 ubuntu kernel: [  485.571613] raid5: allocated 4274kB for md1
Jun  2 23:02:28 ubuntu kernel: [  485.571615] raid5: raid level 5 set md1 active with 3 out of 4 devices, algorithm 2
Jun  2 23:04:00 ubuntu kernel: [  577.515301] md: bind<sdb1>
Jun  2 23:04:01 ubuntu kernel: [  577.993832] md: recovery of RAID array md1
Jun  2 23:04:01 ubuntu kernel: [  577.993835] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Jun  2 23:04:01 ubuntu kernel: [  577.993837] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Jun  2 23:04:01 ubuntu kernel: [  577.993840] md: using 128k window, over a total of 976759936 blocks.

Hoffe mal eine von euch hat da einen Tip was ich machen muss?
Es geht hier ja auch um die Zukunft wenn mal wirklich eine HDD einen defekt hat.
Kann ja nicht sein das durch add der das nicht richtig rebuilded.

Danke für eure Antworten.

mfg

 

[broedel.org]

Hmm allerdings komisch.

Hast du /dev/sdc1 mal gelöscht bevor du sie ins Array integriert hast? Ich meine damit besonders den Superblock. (lässt sich glaube ich mit mdadm -E /dev/sdc1 löschen oder so).

Dein Problem ist aber garantiert, dass die eine Platte als Spare eingerichtet ist. Ein Spare-Drive wird natürlich erst dann "aktiv", wenn das Array degraded ist. Ich vermute mdadm gerät da ein wenig durcheinander mit dem "degraded Trick" (was nebenbei erwähnt ein richtig cooles feature ist, wie ich finde ).

Ich habe ein ähnliches RAID 5, einfach mit 500 GB Platten. Das habe ich auch schon ein paar mal rebuilded, allerdings war die entsprechende Platte nie "spare", auch während des Rebuilds nicht:

mdadm --detail /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Sun May 13 16:50:23 2007
     Raid Level : raid5
     Array Size : 1465151808 (1397.28 GiB 1500.32 GB)
  Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Thu Jun  4 03:37:14 2009
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : bc50e5d7:b76ff944:3ce51b51:b4f7f9a1
         Events : 0.6688100

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       1       8       65        1      active sync   /dev/sde1
       2       8       33        2      active sync   /dev/sdc1
       3       8       17        3      active sync   /dev/sdb1

 

[Fubbel]

hallo,

erstmal danke für deine antwort.

Mein Problem hat sich gestern Nacht erledigt.
Zumindest insoweit das eine der HDD's defekt ist. badblocks brachte ja keine Fehler. Hab dann einfach noch 2 mal den Rebuild gestartet.
Beim zweiten Rebuild, der bevor er fertig war abbrach konnte ich in syslog folgendes finden.

raid5:md1: read error not correctable (sector 849658080 on sda1).
raid5:md1: read error not correctable (sector 849658088 on sda1).
raid5:md1: read error not correctable (sector 849658096 on sda1).
raid5:md1: read error not correctable (sector 849658104 on sda1).
md: md1: recovery done.

Von den Sektorfehlern gibt es noch einige mehr, ist nur ein kleiner Teil.
Danach war das Raid wieder nicht mehr ansprechbar und 2 HDD's (wieder sda1 sdb1) wurden rausgeworfen. Mit assemble konnte ich das Raid wieder so herstellen das ich Zugriff darauf hatte.

sda1 hing ja bereits im Raid 5 mit drin. Die Daten die bereits drauf waren (knapp 1TB), konnte ich ohne Probleme auf eine einzelne HDD sichern. Werde diese HDD erstmal tauschen müssen.

Zwecks löschen der Superblocks. Hatte zwischendurch dann auch mal Acronis Disk Director durchlaufen lassen mit einem richtigen delte Vorgang. Ähnlich wie 00ler draufschreiben.

Wie rebuildest du dein Array? Also mit welchem Befehl?
mdadm --add /dev/md1 /dev/HDD
Mit diesem Befehl wurde das Laufwerk automatisch als Spare eingefügt. Konnte aber auch nichts finden um ein Spare in ein normalers Device zu ändern.
Von der Logik mit Spare Drive ist mir das klar, bzw. kenne ich mich aus. mdadm benutze ich aber erst seit neuem?
Gibt es eine Möglichkeit das Array mittels mdadm prüfen zu lassen? Eine Art verify. Eventuell auch Sektorprüfung der einzelnen HDD's?
Wie z.B. bei den 3ware Controllern. Da kann man ja zeitgesteuert verify laufen lassen.
Ich konnte in mdadm eine Art verify aber nicht finden? Hab ich das übersehen?

mfg

 

[Fubbel]

Zur vervollständigung....

Habe die Festplatte ersetzt und alles neu aufgesetzt. Dieses mal explizit --spare-devices=0 gesetzt beim create Prozess.
Raid5 wieder erstmal nur mit 3 Festplatten und eine als missing.

Nachdem hinzufügen der 4ten HDD, wurde diese während des Rebuilds auf Spare gesetzt, wie die ganze Zeit auch.
Nach Durchlauf des Rebuilds wurde diese automatisch in das Array übernommen und es gibt nun keine Spare Disk mehr.

mfg

 

[broedel.org]

Wie z.B. bei den 3ware Controllern. Da kann man ja zeitgesteuert verify laufen lassen.

Das passiert automatisch (soweit ich weiss). Ich habe da einen Cron:

57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet

Dieser befindet sich unter /etc/cron.d/mdadm und war automatisch nach Installation vorhanden.

Ich glaube der eigentliche Trigger für den Array check sieht so aus:

echo "1" > /sys/block/$array/md/sync_action

Dann kannst du mit cat /etc/mdstat sehen, dass das Array gecheckt wird. Funktioniert tadellos.


Bei dem Spare/nicht Spare Ding machst du mich gerade unsicher. Wie du siehst, existiert mein Array seit 2007 (non-stop 24h am Tag ) und ich weiss nicht mehr genau, was da passiert ist beim Rebuild. Ich bin wir zwar ziemlich sicher, dass das Drive nie spare war.

Aber wenn es mit einer nicht defekten Platte funktioniert, dann umso besser

Den Array habe ich noch nie "manuell" rebuliden müssen. Ich habe das kaputte Drive ersetzt, entsprechend die Partition eingerichtet (Linux RAID) und mit --add hinzugefügt (dann werden ja die Superblocks geschrieben und die Platte "weiss" dann, dass sie zum Array gehört). Der Rebuild erfolgte automatisch, direkt nach dem --add.

Lg

P.S. Deine Festplatte kannst du übrigens mit den smartmontools überprüfen (also ob SMART etwas meldet):

smartctl -a /dev/sdx