Software Raid 5 (Linux) - dirty degraded

[stiV]

Hallo!

Folgendes Problem: Hab auf einem kleinen Server ein Software RAID5 laufen (system ist debian mit einem 2.6er kernel) - und zwar mit 8 stück 300GB festplatten [iDE - alle an zwei promise controllern]. hat jetzt einige zeit einwandfrei funktioniert, auch einen stromausfall [nein hab keine USV dran] überlebt.

vorhin ist der rechner einfach stehen geblieben --- ftp/http/ssh warn tot, also keine reaktion und der bildschirm hat nichts mehr angezeigt. hat also nur ein reset geholfen ... problem: das raid array geht nicht mehr. doch vorher zum syslog weshalb das ding überhaupt abgeschmiert ist:

Jan  9 13:41:38 klo kernel: hdi: lost interrupt

Jan  9 13:41:48 klo kernel: hdl: dma_timer_expiry: dma status == 0x61

Jan  9 13:41:58 klo kernel: hdl: DMA timeout error

Jan  9 13:41:58 klo kernel: hdl: dma timeout error: status=0x50 { DriveReady SeekComplete }

Jan  9 13:41:58 klo kernel: ide: failed opcode was: unknown

Jan  9 13:42:08 klo kernel: hdi: lost interrupt

Jan  9 13:42:18 klo kernel: hdk: dma_timer_expiry: dma status == 0x21

hab das system so gebaut, dass beim booten alle platten durchsucht werden und die arrays (in dem rechner sind noch zwei platten die RAID0 machen - für unwichtiges als zwischenspeicher, das geht noch), hier also der rest des syslogs:

Jan  9 13:50:18 klo kernel: md: Autodetecting RAID arrays.

Jan  9 13:50:18 klo kernel: md: autorun ...

Jan  9 13:50:18 klo kernel: md: considering hdb1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdb1 ...

Jan  9 13:50:18 klo kernel: md:  adding hda5 ...

Jan  9 13:50:18 klo kernel: md: hdl1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hdk1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hdj1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hdi1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hdh1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hdg1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hdf1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: hde1 has different UUID to hdb1

Jan  9 13:50:18 klo kernel: md: created md1

Jan  9 13:50:18 klo kernel: md: bind<hda5>

Jan  9 13:50:18 klo kernel: md: bind<hdb1>

Jan  9 13:50:18 klo kernel: md: running: <hdb1><hda5>

Jan  9 13:50:18 klo kernel: md1: setting max_sectors to 128, segment boundary to 32767

Jan  9 13:50:18 klo kernel: raid0: looking at hdb1

Jan  9 13:50:18 klo kernel: raid0:   comparing hdb1(156288256) with hdb1(156288256)

Jan  9 13:50:18 klo kernel: raid0:   END

Jan  9 13:50:18 klo kernel: raid0:   ==> UNIQUE

Jan  9 13:50:18 klo kernel: raid0: 1 zones

Jan  9 13:50:18 klo kernel: raid0: looking at hda5

Jan  9 13:50:18 klo kernel: raid0:   comparing hda5(145910208) with hdb1(156288256)

Jan  9 13:50:18 klo kernel: raid0:   NOT EQUAL

Jan  9 13:50:18 klo kernel: raid0:   comparing hda5(145910208) with hda5(145910208)

Jan  9 13:50:18 klo kernel: raid0:   END

Jan  9 13:50:18 klo kernel: raid0:   ==> UNIQUE

Jan  9 13:50:18 klo kernel: raid0: 2 zones

Jan  9 13:50:18 klo kernel: raid0: FINAL 2 zones

Jan  9 13:50:18 klo kernel: raid0: zone 1

Jan  9 13:50:18 klo kernel: raid0: checking hda5 ... nope.

Jan  9 13:50:18 klo kernel: raid0: checking hdb1 ... contained as device 0

Jan  9 13:50:18 klo kernel:   (156288256) is smallest!.

Jan  9 13:50:18 klo kernel: raid0: zone->nb_dev: 1, size: 10378048

Jan  9 13:50:18 klo kernel: raid0: current zone offset: 156288256

Jan  9 13:50:18 klo kernel: raid0: done.

Jan  9 13:50:18 klo kernel: raid0 : md_size is 302198464 blocks.

Jan  9 13:50:18 klo kernel: raid0 : conf->hash_spacing is 291820416 blocks.

Jan  9 13:50:18 klo kernel: raid0 : nb_zone is 2.

Jan  9 13:50:18 klo kernel: raid0 : Allocating 8 bytes for hash.

Jan  9 13:50:18 klo kernel: md: considering hdl1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdl1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdk1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdj1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdi1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdh1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdg1 ...

Jan  9 13:50:18 klo kernel: md:  adding hdf1 ...

Jan  9 13:50:18 klo kernel: md:  adding hde1 ...

Jan  9 13:50:18 klo kernel: md: created md0

Jan  9 13:50:18 klo kernel: md: bind<hde1>

Jan  9 13:50:18 klo kernel: md: bind<hdf1>

Jan  9 13:50:18 klo kernel: md: bind<hdg1>

Jan  9 13:50:18 klo kernel: md: bind<hdh1>

Jan  9 13:50:18 klo kernel: md: bind<hdi1>

Jan  9 13:50:18 klo kernel: md: bind<hdj1>

Jan  9 13:50:18 klo kernel: md: bind<hdk1>

Jan  9 13:50:18 klo kernel: md: bind<hdl1>

Jan  9 13:50:18 klo kernel: md: running: <hdl1><hdk1><hdj1><hdi1><hdh1><hdg1><hdf1><hde1>

Jan  9 13:50:18 klo kernel: md: kicking non-fresh hdf1 from array!

Jan  9 13:50:18 klo kernel: md: unbind<hdf1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdf1)

Jan  9 13:50:18 klo kernel: md: md0: raid array is not clean -- starting background reconstruction

Jan  9 13:50:18 klo kernel: raid5: device hdl1 operational as raid disk 1

Jan  9 13:50:18 klo kernel: raid5: device hdk1 operational as raid disk 0

Jan  9 13:50:18 klo kernel: raid5: device hdj1 operational as raid disk 3

Jan  9 13:50:18 klo kernel: raid5: device hdi1 operational as raid disk 2

Jan  9 13:50:18 klo kernel: raid5: device hdh1 operational as raid disk 5

Jan  9 13:50:18 klo kernel: raid5: device hdg1 operational as raid disk 4

Jan  9 13:50:18 klo kernel: raid5: device hde1 operational as raid disk 6

Jan  9 13:50:18 klo kernel: raid5: cannot start dirty degraded array for md0

Jan  9 13:50:18 klo kernel: RAID5 conf printout:

Jan  9 13:50:18 klo kernel:  --- rd:8 wd:7 fd:1

Jan  9 13:50:18 klo kernel:  disk 0, o:1, dev:hdk1

Jan  9 13:50:18 klo kernel:  disk 1, o:1, dev:hdl1

Jan  9 13:50:18 klo kernel:  disk 2, o:1, dev:hdi1

Jan  9 13:50:18 klo kernel:  disk 3, o:1, dev:hdj1

Jan  9 13:50:18 klo kernel:  disk 4, o:1, dev:hdg1

Jan  9 13:50:18 klo kernel:  disk 5, o:1, dev:hdh1

Jan  9 13:50:18 klo kernel:  disk 6, o:1, dev:hde1

Jan  9 13:50:18 klo kernel: raid5: failed to run raid set md0

Jan  9 13:50:18 klo kernel: md: pers->run() failed ...

Jan  9 13:50:18 klo kernel: md: do_md_run() returned -5

Jan  9 13:50:18 klo kernel: md: md0 stopped.

Jan  9 13:50:18 klo kernel: md: unbind<hdl1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdl1)

Jan  9 13:50:18 klo kernel: md: unbind<hdk1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdk1)

Jan  9 13:50:18 klo kernel: md: unbind<hdj1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdj1)

Jan  9 13:50:18 klo kernel: md: unbind<hdi1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdi1)

Jan  9 13:50:18 klo kernel: md: unbind<hdh1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdh1)

Jan  9 13:50:18 klo kernel: md: unbind<hdg1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hdg1)

Jan  9 13:50:18 klo kernel: md: unbind<hde1>

Jan  9 13:50:18 klo kernel: md: export_rdev(hde1)

Jan  9 13:50:18 klo kernel: md: ... autorun DONE.

die zeile

Jan  9 13:50:18 klo kernel:  --- rd:8 wd:7 fd:1

heißt für mich aber, dass nur EINE platte nicht reinpasst - also müsste das RAID5 noch ok sein? hab das [bevor die daten draufgekommen sind] auch ausführlich getestet (was passiert wenn ich zB. einer platte einfach den strom oder das IDE kabel nehm) - und alles was dann war, war dass das array neu gesynct wurde, sonst aber nichts.

hat irgendjemand eine idee? bin e in der zwischenzeit auch am googeln, das prolem ist, dass ich keine 2TB frei hab um die platten zu sichern...

[stiV]

hab einen kollegen gefragt, der mir einen befehl gesagt hat, den ich bis jetzt noch nie wo gelesen oder gesehen hätte (in keiner howto, keinem forum, ...):

einfach als root "mdrun" eingeben ... ohne parameter, dann macht er das gleiche wie beim booten --- erkennt die platten, startet allerdings das raid auch mit nur 7 platten und verweigert nicht mit der netten "dirty degraded" meldung (was für mich SCHLIMM klingt, mir is das herz in die hose gerutscht).

danach konnte ich die hdf (die keinerlei SMART fehler aufweist) mit "mdadm --manage --add" zum wieder laufenden md0 hinzufügen und er hat sofort mit dem sync begonnen ... zwar sehr langsam, aber die 2TB sind auch gut 2/3 voll.

*aufatme*

[dr.disk]

mdrun ist aber dokumentiert. Das nur so nebenbei...

Zurück zum Thema: unter /proc/mdstat kannst Du Dir immer den aktuellen Status Deiner Raids ansehen. Da ist dann auch vermerkt falls eine Platte ausgefallen sein sollte.

[stiV]

ich habs mdrun leider nicht gefunden ... schon gar nicht als "lösung" für das "dirty degraded array" problem, aber viell. war ich auch nur zu blöd :confused:

/proc/mdstat kenn ich natürlich - nur dass md0 nicht mal initialisiert war, da is einfach nix gestanden [bzw. nur md1 - das raid0] :-) nach mdrun wars da, mit den U's und dem schönen unterstrich für die ausgefallene platte - und inzwischen auch schon wieder zu 20% gesynct :marine

[stiV]

achja: da ich nicht genau weiß was der im hintergrund macht - außer irgendwelche netten algorithmen drüberlaufen lassen, wollt ich fragen, ob es sein kann dass der erste sync (ohne daten - hab während dem ersten sync auch absichtlich nix getan mit dem array) viel schneller gegangen ist, als der jetzt mit ~1/2 bis 2/3 voll!?

[mias]

achja: da ich nicht genau weiß was der im hintergrund macht - außer irgendwelche netten algorithmen drüberlaufen lassen, wollt ich fragen, ob es sein kann dass der erste sync (ohne daten - hab während dem ersten sync auch absichtlich nix getan mit dem array) viel schneller gegangen ist, als der jetzt mit ~1/2 bis 2/3 voll!?

Natürlich kann das sein, das muß es sogar, denn er muß schließlich 1/8 deiner Daten/Prüfsummen (deine Konfiguration mit 8 Platten gegeben) aus den Püfsummen/Daten zurück berechnen. 1/8 von 2 TB berechnet sich halt nicht so schnell wie 1/8 von ein paar GB.