md-raid1 nach reboot gesplittet, mdadm, debian wheezy

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Wed, 26 Sep 2012 22:12:40 +0200
Hallo zusammen,

vergangenes WE hatte ich auf einem Server (Stadtwiki Karlsruhe, Debian
wheezy) das Phänomen, dass "einfach so" eine von 2 Platten hing und kurz 
drauf vom Kernel abgemeldet wurde. Das darauf befindliche RAID war 
degraded. Soweit so normal, lief alles noch.

Hier das Setup:
----------------------------------------
$ cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda2[0] sdb2[1]
      1464613824 blocks [2/2] [UU]
      
md0 : active raid1 sda1[0] sdb1[1]
      523200 blocks [2/2] [UU]
      
unused devices: <none>
----------------------------------------
# pvs
  PV         VG   Fmt  Attr PSize PFree
  /dev/md1   vg00 lvm2 a--  1.36t 942.76g

# mount | grep md0 
/dev/md0 on /boot type ext2 (rw,relatime,errors=continue)
----------------------------------------

Der Fehler sah mir nicht aus wie ein "typischer Plattenfehler", mehr
eine Art-SATA-Bus-Fehler von /dev/sdb

Ich entschloss mich zum Reboot (Kiste ist noch nicht produktiv), nach
dem reboot folgendes Phänomen, was ich schon krass fand: 

Die vormals als defekt rausgehauene Platte /dev/sdb war nach dem Reboot 
wieder aktiv, hatte ich ohnehin vermutet. 

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.

Genau das ging aber nicht, weil die 2. Platte (md127, degraded) von LVM
als Pysical Volume erkannt wurde, mit der identischen ID wie md1 und LVM
hat dann gewürfelt und das Physical Volume /dev/md127 verwendet.

Der Stand von /dev/sdb2 alias /dev/md127 war natuerlich deutlich älter
als der von /dev/sda2, allerdings durch die Bevorzugung des Physical
Volumes von /dev/md127 (alias /dev/sdb2) war es teschnisch gesehen
aktueller. 

Problemlösung: Rescue-System booten ohne LVM, RAID-Superblocks von sdb1
und sdb2 löschen und manuell die beiden Raids /dev/md0 (sda1+sdb1,
/boot) und /dev/md1 (sda2+sdb2, LVM) wieder zusammengesteckt.
Freundlicherweise hat letztendlich der Requild dann auch geklappt. Danke
an Markus für die Hilfe mit mdadm.

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?

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.

Ich halte das zu mindest für einen systematischen Bug, der bei ähnlichem
Ablauf immer wieder in dieser Form passieren wird.

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? 

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?




PS: Hier noch dmesg seit dem letzten Boot

[    6.318915] sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
[    6.318974] sd 1:0:0:0: [sdb] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
[    6.319010] sd 1:0:0:0: [sdb] Write Protect is off
[    6.319013] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    6.319028] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    6.319210] sd 0:0:0:0: [sda] Write Protect is off
[    6.319262] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    6.319276] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    6.321269] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    6.321401] sd 1:0:0:0: Attached scsi generic sg1 type 0
[    6.327532]  sda: sda1 sda2
[    6.328287] sd 0:0:0:0: [sda] Attached SCSI disk
[   10.766985]  sdb: sdb1 sdb2
[   10.767937] sd 1:0:0:0: [sdb] Attached SCSI disk
[   11.487263] md: raid0 personality registered for level 0
[   11.488539] md: raid1 personality registered for level 1
[   11.555469] raid6: int64x1   2826 MB/s
[   11.623323] raid6: int64x2   2705 MB/s
[   11.691162] raid6: int64x4   2366 MB/s
[   11.759004] raid6: int64x8   2260 MB/s
[   11.826855] raid6: sse2x1    6899 MB/s
[   11.894697] raid6: sse2x2    8067 MB/s
[   11.962550] raid6: sse2x4    9112 MB/s
[   11.962599] raid6: using algorithm sse2x4 (9112 MB/s)
[   11.963259] async_tx: api initialized (async)
[   11.964630] xor: automatically using best checksumming function: generic_sse
[   11.982501]    generic_sse: 10604.000 MB/sec
[   11.982551] xor: using function: generic_sse (10604.000 MB/sec)
[   11.987529] md: raid6 personality registered for level 6
[   11.987582] md: raid5 personality registered for level 5
[   11.987633] md: raid4 personality registered for level 4
[   11.992963] md: raid10 personality registered for level 10
[   11.995892] 3ware Storage Controller device driver for Linux v1.26.02.003.
[   11.998213] 3ware 9000 Storage Controller device driver for Linux v2.26.02.014.
[   12.001003] Adaptec aacraid driver 1.1-7[28000]-ms
[   12.046892] md: md0 stopped.
[   12.048085] md: bind<sdb1>
[   12.048459] md: bind<sda1>
[   12.049522] bio: create slab <bio-1> at 1
[   12.049706] md/raid1:md0: active with 2 out of 2 mirrors
[   12.049770] md0: detected capacity change from 0 to 535756800
[   12.051249]  md0: unknown partition table
[   12.083376] md: md1 stopped.
[   12.084471] md: bind<sdb2>
[   12.084756] md: bind<sda2>
[   12.086014] md/raid1:md1: active with 1 out of 2 mirrors
[   12.086079] md1: detected capacity change from 0 to 1499764555776
[   12.088771]  md1: unknown partition table
[   12.090006] device-mapper: uevent: version 1.0.3
[   12.090122] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel_at_redhat.com
[   12.463608] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[   12.465352] SGI XFS Quota Management subsystem
[   12.466697] XFS (dm-0): Mounting Filesystem
[   12.582541] RAID1 conf printout:
[   12.582545]  --- wd:1 rd:2
[   12.582548]  disk 0, wo:0, o:1, dev:sda2
[   12.582551]  disk 1, wo:1, o:1, dev:sdb2
[   12.582779] md: recovery of RAID array md1
[   12.582830] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[   12.582882] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
[   12.582956] md: using 128k window, over a total of 1464613824k.
[   12.671183] XFS (dm-0): Ending clean mount
[...]
[   15.998599] EXT2-fs (md0): warning: mounting unchecked fs, running e2fsck is recommended
[   16.014248] XFS (dm-1): Mounting Filesystem
[   16.144740] XFS (dm-1): Ending clean mount
[   16.215630] XFS (dm-2): Mounting Filesystem
[   16.330350] XFS (dm-2): Ending clean mount
[   16.355006] XFS (dm-4): Mounting Filesystem
[   16.460521] XFS (dm-4): Ending clean mount
[   16.527223] XFS (dm-6): Mounting Filesystem
[   17.152852] XFS (dm-6): Ending clean mount
[   17.155766] XFS (dm-5): Mounting Filesystem
[   17.260590] XFS (dm-5): Ending clean mount
[30982.786164] md: md1: recovery done.
[30982.959018] RAID1 conf printout:
[30982.959022]  --- wd:2 rd:2
[30982.959025]  disk 0, wo:0, o:1, dev:sda2
[30982.959028]  disk 1, wo:0, o:1, dev:sdb2

-- 
Raphael Eiselstein <rabe@uugrn.org>               http://rabe.uugrn.org/
xmpp:freibyter@gmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..


-- 
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 26.09.2012

Dieses Archiv wurde generiert von hypermail 2.2.0 : 26.09.2012 CEST