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

Autor: Markus Hochholdinger <Markus_at_hochholdinger.net>
Datum: Fri, 28 Sep 2012 17:52:45 +0200
Hallo Raphael,

ich befürchte Du bist von folgendem Bug betroffen gewesen:
http://www.heise.de/open/meldung/Fehler-im-Linux-Kernel-kann-Software-RAIDs-
zerstoeren-1620896.html

Linux-RAID funktioniert normalerweise so wie Du es erwartet hättest!


Am 26.09.2012 um 22:12 Uhr schrieb Raphael Eiselstein <rabe_at_uugrn.org>:
> 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

Gruß
                                                          \|/
       eMHa                                              (o o)
------------------------------------------------------oOO--U--OOo--
 Markus Hochholdinger
 e-mail  mailto:Markus_at_Hochholdinger.net             .oooO
 www     http://www.hochholdinger.net                (   )   Oooo.
------------------------------------------------------\ (----(   )-
Ich will die Welt verändern,                           \_)    ) /
aber Gott gibt mir den Quelltext nicht!                      (_/


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

Dieses Archiv wurde generiert von hypermail 2.2.0 : 28.09.2012 CEST