Cause: Multipath was not checking the device type and wwid blacklists as soon as this information was available for a path device
Consequence: Multipath could hang for a long time before determining that a path device was invalid.
Fix: Multipath now checks the device type and wwid blacklists as soon as this information is available for a path device
Result: Multipath no longer hangs for a while before blacklisting invalid paths.
Description of problem:
multipath -ll command can take a long time to complete processing a device that
should have been blacklisted by vendor.
Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.9-56.el6.x86_64
How reproducible:
Every time.
Steps to Reproduce:
1. Insert USB Floppy drive, wait for kernel to give it device node.
2. Run multipath -ll -v3
Actual results:
Watch multipath open USB floppy device node and appear to hang. About a
minute later, multipath continues.
Expected results:
Multipath should have consulted the blacklist given information present in
sysfs, like vendor/model/etc. and stopped processing this device.
Additional info:
Attached a USB floppy to box which has a few multipath LUNS.
[root@localhost ~]# lsscsi | grep USB
[357:0:0:0] disk NEC USB UF000x 1.50 /dev/sdy
[root@localhost ~]# multipath -ll -v4
Sep 20 09:57:53 | Discover device /sys/block/sr1
Sep 20 09:57:53 | sr1: device node name blacklisted
[ ... snip a bunch of blacklisted devices ... ]
Sep 20 09:57:53 | Discover device /sys/block/sdy
Sep 20 09:57:53 | sdy: not found in pathvec
Sep 20 09:57:53 | sdy: mask = 0x5
Sep 20 09:57:53 | sdy: dev_t = 65:128
Sep 20 09:57:53 | sdy: size = 2880
Sep 20 09:57:53 | sdy: subsystem = scsi
Sep 20 09:57:53 | sdy: vendor = NEC
Sep 20 09:57:53 | sdy: product = USB UF000x
Sep 20 09:57:53 | sdy: rev = 1.50
Sep 20 09:57:53 | sdy: h:b:t:l = 357:0:0:0
Sep 20 09:58:16 | sdy: get_state
Sep 20 09:58:16 | loading /lib64/multipath/libcheckreadsector0.so checker
Sep 20 09:58:16 | sdy: path checker = readsector0 (config file default)
Sep 20 09:58:16 | sdy: checker timeout = 30000 ms (sysfs setting)
Sep 20 09:58:16 | sdy: state = running
Sep 20 10:00:28 | sdy: state = 2
Sep 20 10:00:28 | sdy: checker msg is "readsector0 checker reports path is down"
So here we notice that multipath decides that device *names* like "sr1" are
blacklisted, an no further processing of them is done.
A reminder of what the blacklist and its exceptions look from
/etc/multipath.conf:
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
device {
vendor "*"
product "*"
}
}
# Make sure our multipath devices are enabled.
blacklist_exceptions {
device {
vendor "Stratus"
product "AA-D91900"
}
device {
vendor "Stratus"
product "AA-D95000"
}
device {
vendor "Stratus"
product "AA-D95200"
}
}
Since the USB floppy drive is assigned "sdy", it passes the device node name
blacklist test and multipath decides to take a closer look.
The multipath user side call trace (read top-down)...
libmultipath/discovery.c:
path_discover(vector pathvec, struct config * conf, char * devname, int flag)
if (filter_devnode(conf->blist_devnode, conf->elist_devnode,
devname) > 0)
return 0;
[ ... snip ... ]
pp = store_pathinfo(pathvec, conf->hwtable,
devname, flag);
store_pathinfo(vector pathvec, vector hwtable, char * devname, int flag)
if (pathinfo(pp, hwtable, flag))
goto out;
pathinfo(struct path *pp, vector hwtable, int mask)
/*
* fetch info available in sysfs
*/
if (mask & DI_SYSFS && sysfs_pathinfo(pp))
return 1;
/*
* fetch info not available through sysfs
*/
if (pp->fd < 0)
pp->fd = opennode(pp->dev, O_RDONLY);
opennode(char * dev, int mode)
return open(devpath, mode);
Notice that path_discover will return if the device node name doesn't pass
the blacklist filter. That is how devices like "sr1" are handled.
In the case of "sdy", it continues on into store_pathinfo, then pathinfo
where information from sysfs is first retrieved, then more information by
opening the device node. This is where the process appears to hang.
Earlier in pathinfo, the sysfs_pathinfo call (by way of scsi_sysfs_pathinfo)
filled in the struct path *pp structure with information like the vendor,
product, revision... All information included in the blacklist.
Unfortunately the information required to consult the blacklist was not
propagated down this far in the call stack.
On RHEL 6.3 GA device-mapper-multipath-0.4.9-56.el6.x86_64, multipath will try to check path status even disk is blacklisted:
===
===== paths list =====
uuid hcil dev dev_t pri dm_st chk_st vend/prod/rev dev_st
1:0:0:0 sda 8:0 -1 undef undef ATA,WDC WD1600BEVS-0 running
===
On device-mapper-multipath-0.4.9-63.el6.x86_64, it dirrectly skip blacklisted paths:
===== no paths =====
VERIFY.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2013-0458.html
Description of problem: multipath -ll command can take a long time to complete processing a device that should have been blacklisted by vendor. Version-Release number of selected component (if applicable): device-mapper-multipath-0.4.9-56.el6.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Insert USB Floppy drive, wait for kernel to give it device node. 2. Run multipath -ll -v3 Actual results: Watch multipath open USB floppy device node and appear to hang. About a minute later, multipath continues. Expected results: Multipath should have consulted the blacklist given information present in sysfs, like vendor/model/etc. and stopped processing this device. Additional info: Attached a USB floppy to box which has a few multipath LUNS. [root@localhost ~]# lsscsi | grep USB [357:0:0:0] disk NEC USB UF000x 1.50 /dev/sdy [root@localhost ~]# multipath -ll -v4 Sep 20 09:57:53 | Discover device /sys/block/sr1 Sep 20 09:57:53 | sr1: device node name blacklisted [ ... snip a bunch of blacklisted devices ... ] Sep 20 09:57:53 | Discover device /sys/block/sdy Sep 20 09:57:53 | sdy: not found in pathvec Sep 20 09:57:53 | sdy: mask = 0x5 Sep 20 09:57:53 | sdy: dev_t = 65:128 Sep 20 09:57:53 | sdy: size = 2880 Sep 20 09:57:53 | sdy: subsystem = scsi Sep 20 09:57:53 | sdy: vendor = NEC Sep 20 09:57:53 | sdy: product = USB UF000x Sep 20 09:57:53 | sdy: rev = 1.50 Sep 20 09:57:53 | sdy: h:b:t:l = 357:0:0:0 Sep 20 09:58:16 | sdy: get_state Sep 20 09:58:16 | loading /lib64/multipath/libcheckreadsector0.so checker Sep 20 09:58:16 | sdy: path checker = readsector0 (config file default) Sep 20 09:58:16 | sdy: checker timeout = 30000 ms (sysfs setting) Sep 20 09:58:16 | sdy: state = running Sep 20 10:00:28 | sdy: state = 2 Sep 20 10:00:28 | sdy: checker msg is "readsector0 checker reports path is down" So here we notice that multipath decides that device *names* like "sr1" are blacklisted, an no further processing of them is done. A reminder of what the blacklist and its exceptions look from /etc/multipath.conf: blacklist { devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z]" device { vendor "*" product "*" } } # Make sure our multipath devices are enabled. blacklist_exceptions { device { vendor "Stratus" product "AA-D91900" } device { vendor "Stratus" product "AA-D95000" } device { vendor "Stratus" product "AA-D95200" } } Since the USB floppy drive is assigned "sdy", it passes the device node name blacklist test and multipath decides to take a closer look. The multipath user side call trace (read top-down)... libmultipath/discovery.c: path_discover(vector pathvec, struct config * conf, char * devname, int flag) if (filter_devnode(conf->blist_devnode, conf->elist_devnode, devname) > 0) return 0; [ ... snip ... ] pp = store_pathinfo(pathvec, conf->hwtable, devname, flag); store_pathinfo(vector pathvec, vector hwtable, char * devname, int flag) if (pathinfo(pp, hwtable, flag)) goto out; pathinfo(struct path *pp, vector hwtable, int mask) /* * fetch info available in sysfs */ if (mask & DI_SYSFS && sysfs_pathinfo(pp)) return 1; /* * fetch info not available through sysfs */ if (pp->fd < 0) pp->fd = opennode(pp->dev, O_RDONLY); opennode(char * dev, int mode) return open(devpath, mode); Notice that path_discover will return if the device node name doesn't pass the blacklist filter. That is how devices like "sr1" are handled. In the case of "sdy", it continues on into store_pathinfo, then pathinfo where information from sysfs is first retrieved, then more information by opening the device node. This is where the process appears to hang. Earlier in pathinfo, the sysfs_pathinfo call (by way of scsi_sysfs_pathinfo) filled in the struct path *pp structure with information like the vendor, product, revision... All information included in the blacklist. Unfortunately the information required to consult the blacklist was not propagated down this far in the call stack.