[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: md-raid1 nach reboot gesplittet, mdadm, debian wheezy
[Thread Prev] | [Thread Next]
[Date Prev] | [Date Next]
- Subject: Re: md-raid1 nach reboot gesplittet, mdadm, debian wheezy
- From: Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>
- Date: Fri, 28 Sep 2012 17:52:45 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Hallo Raphael, ich befuerchte 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 haettest! Am 26.09.2012 um 22:12 Uhr schrieb Raphael Eiselstein <rabe@xxxxxxxxx>: > 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 Gruss \|/ eMHa (o o) ------------------------------------------------------oOO--U--OOo-- Markus Hochholdinger e-mail mailto:Markus@xxxxxxxxxxxxxxxxx .oooO www http://www.hochholdinger.net ( ) Oooo. ------------------------------------------------------\ (----( )- Ich will die Welt veraendern, \_) ) / 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/