Bug 1299600
| Summary: | multipathd does not trigger enough udev events | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ben Marzinski <bmarzins> |
| Component: | device-mapper-multipath | Assignee: | Ben Marzinski <bmarzins> |
| Status: | CLOSED ERRATA | QA Contact: | Zhang Yi <yizhan> |
| Severity: | unspecified | Docs Contact: | Steven J. Levine <slevine> |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | agk, bmarzins, dwysocha, extras-qa, heinzm, lilin, lvm-team, msnitzer, mvollmer, prajnoha, prockai, yizhan, zkabelac |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 08:15:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1254583 | ||
| Bug Blocks: | 1295577, 1313485 | ||
|
Description
Ben Marzinski
2016-01-18 17:50:46 UTC
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 |