Hide Forgot
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.
+++ 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
When multipath adds a new wwid to the wwids file, it now issues a change event on all paths with that wwid.
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>
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).
I've pull the fix into a new build
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