Help needed: Software-RAID ist weg

Hi Sigi,

lass es mal fertig werden (recovery) und mach dann einen fs-check. Normalerweise kann man mit einer Platte weniger auch schreiben, aber bei dir waren 2 Platten rausgeflogen. Ich wuerde die Kiste sich mal beruhigen lassen, dann fsck (vorher unmounten), dann mounten. Und dann mal weiter sehen.

Gruss,
- berndl

Hm na irgendwas stimmt da nicht, zwei Platten sind jetzt als Spare eingerichtet, eine davon is faulty. Bei einem Raid 5 macht aber ein Spare garkeinen Sinn, erst ab 4 Platten.

Zitat

Original von sigiberlin
mhmmm.....

lesen und schreiben vom/auf das Raid funktioniert nicht ....

Sigi, bleib einfach entspannt ... so'n Rebuild eines RAID-Sets (gerade Soft) dauert halt.

Das RAID ist eventuell gelockt, bzw. die CPU ist jetzt unter Volldampf, so dass Deine Schreib-/Lese-Anfragen nicht zeitnah beantworten werden.

SO "cat /proc/mdstat" einen Fortschritt anzeigt,ist alles im grünen Bereich.

Dann probier nochmal, wenigstens sdc1 zu adden:

mdadm –add /dev/md0 /dev/sdc1

Danach nochmal schauen nach cat /proc/mdstat, was passiert.

Das RAID ist gemountet und nicht gecheckt ... daher wohl nur read-only.

Aushängen ... z.B. via auskommentieren in der /etc/fstab ... dann Neustart ... und einen fsck auf's RAID loslassen.

Gruß Miru

Hm, langsam bin ich mit meinem Latein auch am Ende. Hier das wäre noch ne Möglichkeit:

mdadm /dev/md0 --grow -n2

Zitat

mdadm --help --grow
Usage: mdadm --grow device options

This usage causes mdadm to attempt to reconfigure a running array.
This is only possibly if the kernel being used supports a particular
reconfiguration. This version supports changing the number of
devices in a RAID1/5/6, changing the active size of all devices in
a RAID1/4/5/6, adding or removing a write-intent bitmap, and changing
the error mode for a 'FAULTY' array.

Options that are valid with the grow (-G --grow) mode are:
--level= -l : Tell mdadm what level the array is so that it can
: interpret '--layout' properly.
--layout= -p : For a FAULTY array, set/change the error mode.
--size= -z : Change the active size of devices in an array.
: This is useful if all devices have been replaced
: with larger devices.
--raid-disks= -n : Change the number of active devices in an array.
: array.
--bitmap= -b : Add or remove a write-intent bitmap.

Alles anzeigen

Aber alle Angaben ohne Gewähr, hoffe Du hast nen Backup, falls was schief geht.

Zitat

Original von sigiberlin

Code

fileserver2:~#
fileserver2:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc1[3] sdd1[1] sde1[2]
      976767872 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
      [>....................]  recovery =  0.7% (3421952/488383936) finish=267.4min speed=30218K/sec


unused devices: <none>
fileserver2:~#

fileserver2:/# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc1[3](S) sdd1[1] sde1[4](F)
      976767872 blocks level 5, 64k chunk, algorithm 2 [3/1] [_U_]


unused devices: <none>

Jetzt, wo ich die Postings von Sigi vergleiche, denke ich das dort doch ein richtiges Problem besteht.

Wohl nicht von der Hardware ... das hätte Sigi wohl mit logs gepostet ... das ist ein Problem vom Software-RAID.

Wie können wir jetzt Sigi weiter helfen ... in meinem Job hab' ich es nur mit Hardware-RAIDs zu tun.

moin!

Ich hatte anfangs des Jahres große Probleme mit meinen Software RAID5 und leider etwas Erfahrung mit diesem Thema gemacht. Das Problem liegt wahrscheinlich daran das die verwendeten 1,5GB Seagate Platten einfach nicht weiter zu empfehlen sind. (SATA-Kabel dürften auch gern mechanisch etwas stabiler sein.)

Auf alle Fälle habe ich regelmäßig einzelne Platten verloren entsprechend oft Rebuilds laufen gehabt.

Irgendwann war es dann mal so weit das sich das RAID komplett zerlegt hatte und das Device komplett weg war.

Die mdadm Option die unsere Videos gerettet hat war --assume-clean, die --create verlasst den Inhalt der Platte möglichst wenig zu verändern.

mdadm /dev/md1 --create --assume-clean --level 5 --raid-devices 3 /dev/sda3 /dev/sdb3 /dev/sdc3

Danach war das Device /dev/md1 wieder da und nach dem Starten des Volume Managers auch die Logical Volumes.

Danach habe ich fsck über die betroffenen Dateisysteme laufen lassen und (fast) alles war wieder gut.

Falls das Device noch da ist, aber nur noch eine Platte hält und die restlichen fehlen muß man das Device erst mit mdadm --stop anhalten.

Das hat bei mir bisher 2 Mal funktioniert und ich habe keine nennenswerten Datenverluste erlitten, aber ich übernehme natürlich keine Verantwortung für andere Situationen.

Ich drücke sämtliche Daumen!

cu, Stefan

Zitat

Wohl nicht von der Hardware ... das hätte Sigi wohl mit logs gepostet ... das ist ein Problem vom Software-RAID.

Also das halte ich für die unwahrscheinlichste Fehlerquelle - es sei denn, das Problem wäre nach einem "dist-upgrade" aufgetreten.

Ich hatte ähnliches Phänomen mit Maxtor-Platten, die ab einem gewissen Alter zu langsam für den Bootvorgang waren. Dadurch fehlte regelmäßig eine Platte beim Einschalten. Im Log waren keinerlei Fehler auszumachen. Alles Tests, die ich gegen die Platten fuhr, waren in Ordnung - nur ich wusste, dass beim Booten Unregelmäßigkeiten auftraten. Habe dann alle Platten getauscht und seither nimmer das Problem gehabt. Habe auch sonst keine Probleme mit Software-Raid - egal mit welchem Debian.

Bei den Platten war es dann so, dass sie im "normalen" Betrieb auch nimmer lang sauber liefen. Dauerte nicht lange, da wurden die fsck-Laufzeiten immer länger und nach und nach wurden alle aussortiert....

Das "--assume-clean" ist ein guter Tip und wenn das Array nomml hoch kommt, würde ich schnellst möglich die Daten sichern und neue Platten besorgen. Vielleicht wurden ja die Platten beim gleichen Händler zur gleichen Zeit gekauft - und haben somit eine ähnliche Ausfallwahrscheinlichkeit?!?

Gruß Gero

Zitat

md0 : active raid5 sdc1[3](S) sdd1[1] sde1[4](F)

Das (S) sagt doch, dass diese HD als Spare zum RAID5-Set hinzugefügt wurde.

Das (F) müsste bedeuten, dass diese HD im FAULT-Status steht.

Ich kenne md (MetaDevice) nur von SDS (Solaris - Solstice DiskSuite) aus den letzten 10 Jahren. Unter Linux habe ich null md-Erfahrung.

Ich denke aber, dass ein RAID5-Set aus 3 HDs keine Spare haben kann ... so nur 3 HDs vorhanden sind.

Meine Idee wäre den Spare-Status von sdc1 aufzuheben ... dann sollte das RAID5-Set degraded lauffähig sein ... Daten sichern ... sde1 austauschen ... rebuild mit neuer sde1.

Sicher bin ich mir aber auch nicht ... aber so hätte ich es früher unter SDS gemacht.

Gruss Miru

fileserver2:/# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdc1[3](S) sdd1[1] sde1[4](F)
      976767872 blocks level 5, 64k chunk, algorithm 2 [3/1] [_U_]

Das ist faszinierend, hast du tatsaechlich ein Raid5 aus drei platten, wovon eine Spare ist? Das waere der einzige Fall, wo der Ausfall von zwei Platten (eine davon die Spare) zu verkraften ist.

Waere allerdings kein Unterschied zu Raid1 mit einer Spare, daher die Verwirrung.

Zitat

Original von TheChief
Hm, langsam bin ich mit meinem Latein auch am Ende. Hier das wäre noch ne Möglichkeit:

mdadm /dev/md0 --grow -n2

Aber alle Angaben ohne Gewähr, hoffe Du hast nen Backup, falls was schief geht.

Alles anzeigen

Hattest Du das mal (ohne gewähr) probiert?

Na sieht doch gut aus.