RE: RE: Problem with multipathd and a blacklisted device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Try doing this
> without multipathd running, and see if the device still disappears.

Good point! I tried turning off multipathd and temporarily removed the disk.  Lo and behold, the disk path, /dev/hpdev/sda1, was removed!  I guess that this is caused by software RAID and not by multipathd.

Thanks for your suggestion and help.  At least now I know I was looking in the wrong direction.

Lori

> -----Original Message-----
> From: dm-devel-bounces@xxxxxxxxxx
> [mailto:dm-devel-bounces@xxxxxxxxxx] On Behalf Of Benjamin Marzinski
> Sent: Tuesday, March 31, 2009 11:50 AM
> To: device-mapper development
> Subject: Re:  RE: Problem with multipathd and a
> blacklisted device
>
> > > This configuration works well until I do some failure testing
> > > with one of the 2 blacklisted devs in the software RAID set.
> > > I found that if I temporarily remove disk sda and put it back
> > > a minute later the disk path, /dev/hpdev/sda1, is removed,
> > > even though it is blacklisted.
>
> multipathd shouldn't be removing and devices.  It removes
> paths from is
> list of monitored paths, but not from the filesystem.  Try doing this
> without multipathd running, and see if the device still disappears.
>
> That all being said, multipathd shouldn't be monitoring the device
> if it's backlisted.  Did you start up multipathd before you
> blacklisted
> the device?  If so, you need to run
>
> # service multipathd reload
>
> To make multipathd pick up the new configuration. Or you can simply
> restart it. You can check to see if it is monitoring the paths
> by running
>
> # multipathd -k"show paths"
>
> -Ben
>
> > >
> > > Here are some of the pertinent /var/log/messages lines:
> > >
> > > Mar 19 09:53:19 n0 mdadm: NewArray /dev/md0 Mar 19 10:05:12
> > > n0 kernel: mptbase: ioc0: LogInfo(0x31170000):
> > > Originator={PL}, Code={IO Device Missing Delay Retry},
> > > SubCode(0x0000) Mar 19 10:05:40 n0 last message repeated 5
> > > times Mar 19 10:05:42 n0 kernel: mptbase: ioc0:
> > > LogInfo(0x31130000): Originator={PL}, Code={IO Not Yet
> > > Executed}, SubCode(0x0000) Mar 19 10:05:42 n0 kernel: sd
> > > 0:0:28:0: SCSI error: return code = 0x00010000 Mar 19
> > > 10:05:42 n0 kernel: end_request: I/O error, dev sda, sector
> > > 256119 Mar 19 10:05:42 n0 kernel: Buffer I/O error on device
> > > sda1, logical block 256056 Mar 19 10:05:42 n0 kernel: Buffer
> > > I/O error on device sda1, logical block 256057 Mar 19
> > > 10:05:42 n0 kernel: Buffer I/O error on device sda1, logical
> > > block 256058 Mar 19 10:05:42 n0 kernel: Buffer I/O error on
> > > device sda1, logical block 256059 Mar 19 10:05:42 n0 kernel:
> > > Buffer I/O error on device sda1, logical block 256060 Mar 19
> > > 10:05:42 n0 kernel: Buffer I/O error on device sda1, logical
> > > block 256061 Mar 19 10:05:42 n0 kernel: mptbase: ioc0:
> > > LogInfo(0x31130000): Originator={PL}, Code={IO Not Yet
> > > Executed}, SubCode(0x0000) Mar 19 10:05:42 n0 kernel: Buffer
> > > I/O error on device sda1, logical block 256062 Mar 19
> > > 10:05:42 n0 kernel: Buffer I/O error on device sda1, logical
> > > block 256063 Mar 19 10:05:42 n0 kernel: sd 0:0:28:0: SCSI
> > > error: return code = 0x00010000 Mar 19 10:05:42 n0
> > > multipathd: sda: remove path (uevent) Mar 19 10:05:42 n0
> > > kernel: end_request: I/O error, dev sda, sector 585922495 Mar
> > > 19 10:05:42 n0 kernel: Buffer I/O error on device sda1,
> > > logical block 585922432 Mar 19 10:05:42 n0 xinetd[13096]:
> > > START: hacl-cfgudp pid=6034 from=127.0.0.1 Mar 19 10:05:42 n0
> > > multipathd: uevent trigger error Mar 19 10:05:42 n0 kernel:
> > > Buffer I/O error on device sda1, logical block 585922433
> > >
> > >
> > > The sda path is gone:
> > >
> > > /root> ls -l /dev/hpdev
> > > total 0
> > > lrwxrwxrwx 1 root root 7 Mar 18 03:32 sdb1 -> ../sdb1 /root>
> > >
> > > And I cannot reassemble the software raid set.  While the
> > > mdstat looks 'normal' the software raid becomes degraded.
> > >
> > > /etc/udev/rules.d> cat /proc/mdstat
> > > Personalities : [raid1]
> > > md0 : active raid1 sda1[2](F) sdb1[1]
> > >       292961216 blocks [2/1] [_U]
> > >
> > > unused devices: <none>
> > > /etc/udev/rules.d> mdadm --detail /dev/md0
> > > /dev/md0:
> > >         Version : 00.90.03
> > >   Creation Time : Wed Feb 18 14:15:03 2009
> > >      Raid Level : raid1
> > >      Array Size : 292961216 (279.39 GiB 299.99 GB)
> > >     Device Size : 292961216 (279.39 GiB 299.99 GB)
> > >    Raid Devices : 2
> > >   Total Devices : 2
> > > Preferred Minor : 0
> > >     Persistence : Superblock is persistent
> > >
> > >     Update Time : Thu Mar 19 10:28:45 2009
> > >           State : clean, degraded
> > >  Active Devices : 1
> > > Working Devices : 1
> > >  Failed Devices : 1
> > >   Spare Devices : 0
> > >
> > >            UUID : 94813396:a3e341fc:c5d4b8ba:0617a019
> > >          Events : 0.86
> > >
> > >     Number   Major   Minor   RaidDevice State
> > >        0       0        0        0      removed
> > >        1       8       17        1      active sync   /dev/sdb1
> > >
> > >        2       8        1        -      faulty spare
> > > /etc/udev/rules.d>
> > >
> > > The disk is fine and is back in and ready to go.
> > >
> > > So, 1) why does multipathd remove the path for a blacklisted
> > > device?  If it is blacklisted, shouldn't multipathd just
> > > leave it alone??
> > > And 2) what can I do to keep this from happening??
> > >
> > > Lori Ransegnola
> > >
> >
> > --
> > dm-devel mailing list
> > dm-devel@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/dm-devel
>
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/dm-devel
>

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux