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/
Dieses Archiv wurde generiert von hypermail 2.2.0 : 26.09.2012 CEST