Bug 1299600 - multipathd does not trigger enough udev events
Summary: multipathd does not trigger enough udev events
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: device-mapper-multipath
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ben Marzinski
QA Contact: Zhang Yi
Steven J. Levine
URL:
Whiteboard:
Keywords:
Depends On: 1254583
Blocks: 1313485 1295577
TreeView+ depends on / blocked
 
Reported: 2016-01-18 17:50 UTC by Ben Marzinski
Modified: 2016-11-04 08:15 UTC (History)
13 users (show)

(edit)
New devices are now claimed by multipath as soon as multipath creates a multipath device on top of them

Previously, the first time multipath saw a device, it was not claimed by multipath in the `udev` rules since multipath will not claim a device in `udev` unless the the WWID is in the `/etc/multipath/wwids` file when processing the `uevent`. With this fix, when multipath adds a new device WWID to the `wwids` file, it will issue a change event on the device so it can claim it in the `udev` rules. New devices are now claimed by multipath as soon as multipath creates a multipath device on top of them.
Clone Of: 1254583
(edit)
Last Closed: 2016-11-04 08:15:52 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2536 normal SHIPPED_LIVE device-mapper-multipath bug fix and enhancement update 2016-11-03 14:18:10 UTC

Description Ben Marzinski 2016-01-18 17:50:46 UTC
+++ This bug was initially created as a clone of Bug #1254583 +++

Description of problem:

Starting multipathd will correctly set up device mapper for the existing multipath devices, but the ID_FS_TYPE udev property of newly enslaved block devices are not updated.  They are updated only after an explicit "udevadm trigger". 

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.9-73.fc22.x86_64

How reproducible:
Always

Steps to Reproduce:
0. Setup multipath scenario with /dev/sdb and /dev/sdc
1. mpathconf --disable
2. reboot
3. mpathconf --enable
4. systemctl restart multipathd
5. multipathd list paths
5. udevadm info /dev/sda | grep ID_FS_TYPE

Actual results:
# multipathd list paths
hcil    dev dev_t pri dm_st  chk_st dev_st  next_check      
0:0:0:0 sda 8:0   1   undef  ready  running orphan          
2:0:0:0 sdb 8:16  1   active ready  running XXXXXXXXX. 19/20
2:0:1:0 sdc 8:32  1   active ready  running XXXXXXXXX. 19/20
# udevadm info /dev/sdb | grep ID_FS_TYPE
<empty>

Expected results:
# udevadm info /dev/sdb | grep ID_FS_TYPE
E: ID_FS_TYPE=mpath_member

Comment 1 Ben Marzinski 2016-02-26 22:37:37 UTC
When multipath adds a new wwid to the wwids file, it now issues a change event on all paths with that wwid.

Comment 2 Lin Li 2016-05-12 07:35:32 UTC
Reproduced on device-mapper-multipath-0.4.9-85.el7
1. # rpm -qa | grep multipath
device-mapper-multipath-libs-0.4.9-85.el7.x86_64
device-mapper-multipath-0.4.9-85.el7.x86_64
2. Setup multipath scenario with /dev/sdb and /dev/sdc
# multipath -ll
mpatha (360014050e70e2336c7547b9add310ee0) dm-0 LIO-ORG ,st73-io         
size=10G features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 6:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 7:0:0:0 sdc 8:32 active ready running
3. # mpathconf --disable
4. # reboot
5. # mpathconf --enable
6.# service multipathd restart
Redirecting to /bin/systemctl restart  multipathd.service
7. # multipathd list paths
hcil    dev dev_t pri dm_st  chk_st dev_st  next_check     
6:0:0:0 sdb 8:16  1   active ready  running XXX....... 3/10
7:0:0:0 sdc 8:32  1   active ready  running XX........ 2/10
0:0:0:0 sda 8:0   1   undef  ready  running orphan 
8. # udevadm info /dev/sdb | grep ID_FS_TYPE
<empty>
9. # udevadm info /dev/sdc | grep ID_FS_TYPE
<empty>

Comment 7 Ben Marzinski 2016-07-11 20:07:47 UTC
Since multipath only resends a uevent when a wwid is added to the wwids file, this won't effect the reproducer if the wwid for the device already exists in the wwids file. In general this method doesn't fix all situations where a device really wasn't configured to be a path device when it was discovered. It will fix all situations where the device IS configured to be a path device, but since it hasn't been discovered before, it isn't marked as such when it first appears.

A better way to test this is:

0. Have a setup with a valid multipath device.
2. remove the device's wwid from the wwids file with

# multipath -w <device>
3. reboot.

Without this fix, the path devices should not have ID_FS_TYPE set correctly
With this fix, they should.

Solving this for all cases where the users are changing their configuration is trickier, instead of just discovering new devices. I should note that this will still work for cases where the users are changing their configuration if it makes a device become a valid path for the first time. It simply won't work for the case where users blacklist current multipath paths, rediscover those paths, and then unblacklist them (which is what is happening with the mpathconf --disable and --enable commands).

Comment 13 Ben Marzinski 2016-07-15 23:10:14 UTC
I've pull the fix into a new build

Comment 17 errata-xmlrpc 2016-11-04 08:15:52 UTC
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.

https://rhn.redhat.com/errata/RHBA-2016-2536.html


Note You need to log in before you can comment on or make changes to this bug.