[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
md-raid1 nach reboot gesplittet, mdadm, debian wheezy
[Thread Prev] | [Thread Next]
- Subject: md-raid1 nach reboot gesplittet, mdadm, debian wheezy
- From: Raphael Eiselstein <rabe@xxxxxxxxx>
- Date: Wed, 26 Sep 2012 22:12:40 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Hallo zusammen,
vergangenes WE hatte ich auf einem Server (Stadtwiki Karlsruhe, Debian
wheezy) das Phaenomen, 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 Phaenomen, 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
*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.
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 gewuerfelt und das Physical Volume /dev/md127 verwendet.
Der Stand von /dev/sdb2 alias /dev/md127 war natuerlich deutlich aelter
als der von /dev/sda2, allerdings durch die Bevorzugung des Physical
Volumes von /dev/md127 (alias /dev/sdb2) war es teschnisch gesehen
aktueller.
Problemloesung: Rescue-System booten ohne LVM, RAID-Superblocks von sdb1
und sdb2 loeschen 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 fuer 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 *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.
Ich halte das zu mindest fuer einen systematischen Bug, der bei aehnlichem
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 Loeschen des Superblocks erzwingen. Was hat
man hier fuer 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 loeschen 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@xxxxxxxxxx
[ 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@xxxxxxxxx> http://rabe.uugrn.org/
xmpp:freibyter@xxxxxx | 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/