action #97598
closeddiskchecker meldet defekten RAID-Verbund nicht
Description
Beim erste Kunden bei dem ich einen invis-Server 14.3 unter Leap 15.3 aufgebaut habe war ein RAID1 Verbund defekt. Vermutlich hat sich eine der beteiligten Platten während des Server-Transports so im Schacht gelockert, dass sie nicht ansprang. Der Server startete über die verbleibende Platte ohne Probleme. diskchecker hat keinerlei Fehler gemeldet. Da es in diesem Moment keine zweite Platte gab wurde sie logischerweise nicht per SMART abgefragt. So weit so logisch. Allerdings wurde der RAID-Verbund als intakt gemeldet, was ein Riesenproblem darstellt.
Die Ursache konnte ich eingrenzen. Im Script fragen wir den Zustand des Verbundes mittels mdadm -D ab und filtern nach einer Zeile in der "State :" steht. Dort wird üblicherweise der Status des Verbundes angegeben. Hier liegt das Problem, ist der RAID-Verbund defekt fehlt diese Zeile in der Ausgabe von mdadm -D. Das dürfte ein Bug in mdadm sein.
Wir generieren aus der Abfrage eine Variable, die in diesem Falle leer bzw. nicht existent ist, wodurch die bestehende Status-Datei aus der das Portal seine Infos bezieht nicht überschrieben wird. Kurz der Status "OK" bleibt auch im Fehlerfall erhalten.
Das ganze muss einerseits von uns noch genauer analysiert werden. Zum anderen müssen wir dafür sorgen, dass eine leere Variable "$status" zwingend zu einer Fehlermeldung im Portal führt.
Updated by flacco over 2 years ago
An dieser Stelle noch einen ergänzenden Kommentar:
Das wiederherstellen des RAID-Verbundes mittels "mdadm /dev/md0 -a /dev/sdb2" macht mich stutzig.
Wie auf unseren DevDays berichtet hatte ich in einem RAID5 Verbund das Problem, dass der resync nach wieder einbringen einer versehentlich entfernten Platte keinesfalls zu einem intakten RAID-Verbund führte. Der Server blieb nach kurzer Laufzeit stecken und verweigerte den Reboot. Auffällig war, dass der Resync schon nach 1 bis 2 Sekunden fertig war. Es war also kein kompletter Resync, der hätte Stunden gedauert. Der RAID-Verbund war erst wieder intakt, nach dem ich die Platte großzügig mit Nullen überschrieben, neu partitioniert, und dann wieder in den RAID-Verbund aufgenommen hatte. Danach dauerte er auch Stunden....
Im heutigen Fall kam mir der Resync ebenfalls zu schnell vor. Danach ist ein Backupversuch mit invis-bbu des mit BtrFS formatierten Root-Volumes schief gegangen. Ursache war, dass es nicht möglich war den LVM-Scnapshot des root-Volumes zu mounten. Im Systemjournal tauchten ein paar Warnings zum BtrFS Dateisystem auf. Irgendwas mit "doppelten" UUIDs oder so. Konnte ich leider nicht genauer analysieren...
Also: Achtung irgendwas ist mit Linux MD-RAID im Argen!
Updated by flacco over 2 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Mist, verhält sich in der Testumgebung wieder anders als beim Kunden....
Hier ist die State-Zeile in der Ausgabe von mdadm -D vorhanden.
Updated by flacco over 2 years ago
- Status changed from In Progress to Resolved
- % Done changed from 10 to 90
Asche auf mein Haupt. Hab den Fehler im diskchecker Script selbst verursacht.
Updated by flacco over 2 years ago
Ergänzende Bemerkung zur ergänzenden Bemerkung:
Beim Hinzufügen einer Partition zu einem RAID Verbund liefert mdadm zwei verschiedene Ausgaben zurück. Entweder:
invis:~ # mdadm /dev/md0 -a /dev/sdb2
mdadm: added /dev/sdb2
oder
invis:~ # mdadm /dev/md0 -a /dev/sdb2
mdadm: re-added /dev/sdb2
Letzteres ist vermutlich die Situation, bei der Vorsicht geboten ist. Scheint eine Quick-and-Dirty Variante zu sein.