Bug 1299600 - multipathd does not trigger enough udev events
multipathd does not trigger enough udev events
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ben Marzinski
Zhang Yi
Steven J. Levine
:
Depends On: 1254583
Blocks: 1313485 1295577
  Show dependency treegraph
 
Reported: 2016-01-18 12:50 EST by Ben Marzinski
Modified: 2016-11-04 04:15 EDT (History)
13 users (show)

See Also:
Fixed In Version: device-mapper-multipath-0.4.9-93.el7
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: 1254583
Environment:
Last Closed: 2016-11-04 04:15:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben Marzinski 2016-01-18 12:50:46 EST
+++ 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 17:37:37 EST
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 03:35:32 EDT
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 16:07:47 EDT
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 19:10:14 EDT
I've pull the fix into a new build
Comment 17 errata-xmlrpc 2016-11-04 04:15:52 EDT
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.