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):
Steps to Reproduce:
1. Insert USB Floppy drive, wait for kernel to give it device node.
2. Run multipath -ll -v3
Watch multipath open USB floppy device node and appear to hang. About a
minute later, multipath continues.
Multipath should have consulted the blacklist given information present in
sysfs, like vendor/model/etc. and stopped processing this device.
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
# Make sure our multipath devices are enabled.
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)...
path_discover(vector pathvec, struct config * conf, char * devname, int flag)
if (filter_devnode(conf->blist_devnode, conf->elist_devnode,
devname) > 0)
[ ... snip ... ]
pp = store_pathinfo(pathvec, conf->hwtable,
store_pathinfo(vector pathvec, vector hwtable, char * devname, int flag)
if (pathinfo(pp, hwtable, flag))
pathinfo(struct path *pp, vector hwtable, int mask)
* fetch info available in sysfs
if (mask & DI_SYSFS && sysfs_pathinfo(pp))
* 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.
Bug 661984 appears to suffer from the same problem.
multipath now checks the blacklists as soon as it can.
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 =====
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.