RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1299600 - multipathd does not trigger enough udev events
Summary: multipathd does not trigger enough udev events
Keywords:
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:
Depends On: 1254583
Blocks: 1295577 1313485
TreeView+ depends on / blocked
 
Reported: 2016-01-18 17:50 UTC by Ben Marzinski
Modified: 2021-09-03 11:57 UTC (History)
13 users (show)

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.
Clone Of: 1254583
Environment:
Last Closed: 2016-11-04 08:15:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2536 0 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.