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

[Jakob Haufe <sur5r@xxxxxxxxx>]

On Wed, 26 Sep 2012 22:12:40 +0200
Raphael Eiselstein <rabe@xxxxxxxxx> wrote:

> Allerdings hat das RAID keinen Rebuild gemacht (das war mein
> Erwartungswert) sondern die zweite Platte (genauer: sdb1 und sdb2)  als
> jeweils *eigenstaendige* degradete RAIDs erkannt, zu allem Ueberfluss als
> md127 und md126 (IIRC). Auch das war fuer mich noch kein Grund zur Panik,
> ich haette die Platte einfach destroyen und wieder zum md0/md1 zufuegen
> koennen.

Das is natuerlich Ober-Murks, so sollte das definitiv nicht passieren. Passt da
evtl. die mdadm.conf in der initrd nicht zur Realitaet? Ich hab es schon
erlebt, dass 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 waere, waere die Ausgabe von

mdadm --examine /dev/sdXY

fuer 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 ueberschrieben werden
muss. Dass 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 *aeltere* Variante (hier: sdb2 alias md127)? Waere es nicht im Sinn 
> von LVM bei einem UUID-Konflikt der Physical Volumes das *aktuellere* 
> zu verwenden? Dazu muesste LVM etwas ueber die Metadaten von md1 und 
> md127 wissen. Aber denkbar waere es.

LVM hat keinerlei Infos durch die es so eine Situation aufloesen koennte. Er
sieht einfach alles doppelt und da entscheidet dann wohl Kollege Zufalll. Du
koenntest die gueltigen LVM-Devices in der /etc/lvm/lvm.conf auf md0 und md1
oder so einschraenken... aber das geht ja ein bisschen 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 Loeschen des Superblocks erzwingen. Was hat
> man hier fuer Optionen? 

Ich weiss nicht ob in den Superblocks auch die An-/Abwesenheit der restlichen
Komponenten vermerkt wird. Wenn man es noch beeinflussen kann, weil das System
noch laeuft, 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 loeschen oder einen Rebuild zu
> forcieren?

Ja, wobei das natuerlich 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 fuer Bus, ID,
LUN. Du kannst also auch nach einem bestimmten Geraet 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 waere es also host0.

Danach koenntest 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?

Gruesse,
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/