Re: md-raid1 nach reboot gesplittet, mdadm, debian wheezy

Autor: Jakob Haufe <sur5r_at_sur5r.net>
Datum: Thu, 27 Sep 2012 00:35:40 +0200
On Wed, 26 Sep 2012 22:12:40 +0200
Raphael Eiselstein <rabe_at_uugrn.org> wrote:

> Allerdings hat das RAID keinen Rebuild gemacht (das war mein
> Erwartungswert) sondern die zweite Platte (genauer: sdb1 und sdb2)  als
> jeweils *eigenständige* degradete RAIDs erkannt, zu allem Überfluss als
> md127 und md126 (IIRC). Auch das war für mich noch kein Grund zur Panik,
> ich hätte die Platte einfach destroyen und wieder zum md0/md1 zufügen
> können.

Das is natürlich Ober-Murks, so sollte das definitiv nicht passieren. Passt da
evtl. die mdadm.conf in der initrd nicht zur Realität? Ich hab es schon
erlebt, daß da ne veraltete Version drin war... Im Zweifelsfall
mit /usr/share/mdadm/mkconf ne korrekte Version erzeugen und
nach /etc/mdadm.conf legen. Danach initrd neu bauen.

Was hier mal interessant wäre, wäre die Ausgabe von

mdadm --examine /dev/sdXY

für alle Komponenten.

> Das ganze wirft allerdings Fragen auf: Was ist das *normale* Verhalten,
> wenn eine SATA-Platte rausgeworfen wird in Bezug auf ein RAID? Ist es
> *sinnvoll*, dass die zuvor als defekt deklarierte Platte als Volume
> wieder in Betrieb geht?

Eigentlich gibt es Timestamps auf den Komponenten eines RAIDs. Damit eben der
Kernel erkennen kann, welche Platte veraltet ist und überschrieben werden
muss. Daß hier aus der "failed" Komponente ein neues RAID entstanden ist ist
eindeutig nicht im Sinne des Erfinders.

> Im Falle von LVM (ist hier der Fall) wird dieses "md127-Device" *immer*
> die gleiche UUID haben wie der Zwilling /dev/md1 und LVM wird deswegen
> *immer* eine von beiden Platten bevorzugt verwenden. Warum ausgerechnet
> die *ältere* Variante (hier: sdb2 alias md127)? Wäre es nicht im Sinn 
> von LVM bei einem UUID-Konflikt der Physical Volumes das *aktuellere* 
> zu verwenden? Dazu müsste LVM etwas über die Metadaten von md1 und 
> md127 wissen. Aber denkbar wäre es.

LVM hat keinerlei Infos durch die es so eine Situation auflösen könnte. Er
sieht einfach alles doppelt und da entscheidet dann wohl Kollege Zufalll. Du
könntest die gültigen LVM-Devices in der /etc/lvm/lvm.conf auf md0 und md1
oder so einschränken... aber das geht ja ein bißchen am Sinn von LVM vorbei.

> Abhilfe? *vor* dem Reboot das "failed"-Device aus dem RAID abmelden. Da
> das "failed"-device (hier sdb) zu dem Zeitpunkt nicht mehr zugreifbar
> ist, kann man es nicht durch Löschen des Superblocks erzwingen. Was hat
> man hier für Optionen? 

Ich weiß nicht ob in den Superblocks auch die An-/Abwesenheit der restlichen
Komponenten vermerkt wird. Wenn man es noch beeinflussen kann, weil das System
noch läuft, schadet ein "mdadm /dev/mdX --remove failed" sicher nicht.

> Kann man eine Plattem die vom Kernel aufgrund von Channel-Fehlern (SATA)
> abgemeldet wurde durch einen gezielten Reset des SATA-Channels
> "wiederbeleben" um dann die Superblocks zu löschen oder einen Rebuild zu
> forcieren?

Ja, wobei das natürlich immer auf die Schwere des Schluckaufs und den
konkreten Controller ankommt:

echo 1 > /sys/class/block/sdX/device/delete

Danach kannst Du mit

echo - - - > /sys/class/scsi_host/hostX/scan

einen Rescan veranlassen. Die "- - -" stehen hier als Wildcard für Bus, ID,
LUN. Du kannst also auch nach einem bestimmten Gerät suchen lassen.

Welcher Host der richtige ist guckst Du am besten vor dem ersten Kommando
nach:

# readlink /sys/class/block/sda
../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda

Hier wäre es also host0.

Danach könntest Du sie auch wieder in das Array aufnehmen (nach einem
SMART-Test oder so).

> PS: Hier noch dmesg seit dem letzten Boot

Hast Du evtl. noch was in /var/log/kern.log.* vom Zeitpunkt des Fehlers?

Grüße,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 27.09.2012

Dieses Archiv wurde generiert von hypermail 2.2.0 : 27.09.2012 CEST