Bug 1010040 - Multipath needs to reset the ID_FS_TYPE udev attribute on multipath devices
Multipath needs to reset the ID_FS_TYPE udev attribute on multipath devices
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Ben Marzinski
yanfu,wang
:
: 877256 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-19 14:47 EDT by Ben Marzinski
Modified: 2014-06-18 01:14 EDT (History)
7 users (show)

See Also:
Fixed In Version: device-mapper-multipath-0.4.9-56.el7
Doc Type: Bug Fix
Doc Text:
Cause: In its udev rules, multipath was not resetting the ID_FS_TYPE attribute that blkid set on it's path devices. Consequence: lvmetad was not correctly ignoring the path devices. Fix: Multipath now always resets the ID_FS_TYPE for path devices in its udev rules. Result: lvmetad will correctly ignore multipath path devices.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 07:27:48 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)
create timestamp, and add -T option to multipath to check it (11.67 KB, patch)
2013-09-19 20:28 EDT, Ben Marzinski
no flags Details | Diff

  None (edit)
Description Ben Marzinski 2013-09-19 14:47:12 EDT
Description of problem:
To make sure that lvm-metad is using the multipath device itself, instead of the path devices, multipath needs to reset ID_FS_TYPE for the path devices before the 69-dm-lvm-metad.rules are run.

This already happens on "add" events, but it needs to happen on "change" events as well.  However, running multipath on every "change" event to a block device is expensive. If multipath's configuration files (/etc/multipath.conf and /etc/multipath/wwids) haven't changed, then if a device was flagged as a multipath device on the "add" event, it will still be a multipath device. So, if the configuration files haven't changed, the attribute values can just be imported from the udev database.

To do this multipath needs to keep a timestamp that gets updated whenever something changes that requires devices to be rechecked. And the block devices need to save the current timestamp to the udev database when they get a uevent. The only tricky part is how to compare the timestamp values.  It is not currently possible to compare environment variables in udev. Ideally the udev enhancement in Bug #1007650 will be added. As a workaround, multipath can accept the timestamp as a option, and check itself if the value has changed.
Comment 2 Ben Marzinski 2013-09-19 20:28:57 EDT
Created attachment 800241 [details]
create timestamp, and add -T option to multipath to check it

This patch makes multipath create a timestamp file (/run/multipathd/timestamp) when it starts up. This file is updated whenever multipathd is reloaded, or if a wwid is added or removed from the wwids file.  Multipath now supports a -T<timestamp>:<valid> option.  If <timestamp> matches the current timestamp or if there is currently no timestamp (which means multipathd is not running), multipath just uses the value in <valid>, which defaults to not valid (0).  If the timestamps don't match, or <timestamp> doesn't exist, multipath will run the -c check as normal.

The udev rules continue to always check if the device is valid on "add" events. But now the current timestamp is always saved.  On change events, this timestamp is passed to the call with the -T option, along with the previous value of DM_MULTIPATH_DEVICE_PATH. If the timestamp hasn't changed, the old value is retained.  If the timestamp has changed, multipath will actually do the check to determine if the device is a path device.  The goal is to have multipath exit as quickly as possible most of the time, and only do the check in the rare cases when it is actually necessary.
Comment 4 Ben Marzinski 2013-09-25 19:58:09 EDT
*** Bug 877256 has been marked as a duplicate of this bug. ***
Comment 5 Ben Marzinski 2013-09-26 17:04:27 EDT
I've committed the attached patch.
Comment 7 yanfu,wang 2013-11-29 03:32:59 EST
hi Ben,
Below is my test result as per your comment#3:
# modprobe scsi_debug dev_size_mb=512 vpd_use_hostno=0 add_host=2
# multipath -ll
mpathb (353333330000007d0) dm-9 Linux   ,scsi_debug      
size=512M features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 5:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 6:0:0:0 sdc 8:32 active ready running
# pvcreate /dev/mapper/mpathb 
  Physical volume "/dev/mapper/mpathb" successfully created

# udevadm info --export-db |grep DM_MULTIPATH_DEVICE_PATH
E: DM_MULTIPATH_DEVICE_PATH=1
# udevadm info --export-db |grep 'ID_FS_TYPE=mpath_member'
E: ID_FS_TYPE=mpath_member

# echo 1>/sys/block/sdb/device/delete 
# multipath -ll
mpathb (353333330000007d0) dm-9 Linux   ,scsi_debug      
size=512M features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=1 status=active
  `- 6:0:0:0 sdc 8:32 active ready running

remove one device don't effect these values:
# udevadm info --export-db |grep 'ID_FS_TYPE=mpath_member'
E: ID_FS_TYPE=mpath_member
# udevadm info --export-db |grep DM_MULTIPATH_DEVICE_PATH
E: DM_MULTIPATH_DEVICE_PATH=1


re-add:
# echo '- - -' > /sys/class/scsi_host/host5/scan 
# multipath -ll
mpathb (353333330000007d0) dm-9 Linux   ,scsi_debug      
size=512M features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 5:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 6:0:0:0 sdc 8:32 active ready running

I saw duplicate value after re-add:
# udevadm info --export-db |grep DM_MULTIPATH_DEVICE_PATH
E: DM_MULTIPATH_DEVICE_PATH=1
E: DM_MULTIPATH_DEVICE_PATH=1
# udevadm info --export-db |grep 'ID_FS_TYPE=mpath_member'
E: ID_FS_TYPE=mpath_member
E: ID_FS_TYPE=mpath_member

remove all device and no mpath device now, the udev database values removed too:
# echo 1>/sys/block/sdb/device/delete 
# echo 1>/sys/block/sdc/device/delete 
# multipath -l
# udevadm info --export-db |grep 'ID_FS_TYPE=mpath_member'
# udevadm info --export-db |grep DM_MULTIPATH_DEVICE_PATH
# 

Is the above duplicate value an issue?
Comment 8 Ben Marzinski 2013-12-02 12:26:06 EST
You should expect to see that value multiple times.  The duplicated value just means that there is more than one path listed as a multipath device.  You should see that for each multipath path device.  However, you won't see it until the device gets a change event.
Comment 9 yanfu,wang 2013-12-02 21:44:48 EST
(In reply to Ben Marzinski from comment #8)
> You should expect to see that value multiple times.  The duplicated value
> just means that there is more than one path listed as a multipath device. 
> You should see that for each multipath path device.  However, you won't see
> it until the device gets a change event.
hi Ben,
Thanks for the pointer, I still have one question and want to confirm with you again. You mentioned the duplicated value for more than one path, but why I just saw one when multipath assemble first? 
# modprobe scsi_debug dev_size_mb=512 vpd_use_hostno=0 add_host=2
# multipath -ll
mpathb (353333330000007d0) dm-9 Linux   ,scsi_debug      
size=512M features='0' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 5:0:0:0 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 6:0:0:0 sdc 8:32 active ready running
# pvcreate /dev/mapper/mpathb 
  Physical volume "/dev/mapper/mpathb" successfully created

# udevadm info --export-db |grep DM_MULTIPATH_DEVICE_PATH
E: DM_MULTIPATH_DEVICE_PATH=1
# udevadm info --export-db |grep 'ID_FS_TYPE=mpath_member'
E: ID_FS_TYPE=mpath_member
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ see above, there are two path should have two udev values, is it right?

The duplicate value will happen after I remove and re-add the same device.
Comment 10 Ben Marzinski 2013-12-03 12:58:15 EST
I'm more surprised that you saw any DM_MULTIPATH_DEVICE_PATH=1 results the first time.  One of the paths must have gotten a uevent after the multipath device
was created.

Multipath will not count a device as a valid multipath path until it has created
a multipath device with its WWID.  So the first time you see a new device, it will not get labelled as a multipath path. I assume that one of the paths got
a uevent after the multipath device was created (which does not itself trigger a uevent on the path devices). If you delete the devices and re-add them, you should now always see two DM_MULTIPATH_DEVICE_PATH=1 lines.
Comment 11 yanfu,wang 2013-12-03 21:12:43 EST
(In reply to Ben Marzinski from comment #10)
> I'm more surprised that you saw any DM_MULTIPATH_DEVICE_PATH=1 results the
> first time.  One of the paths must have gotten a uevent after the multipath
> device
> was created.
> 
> Multipath will not count a device as a valid multipath path until it has
> created
> a multipath device with its WWID.  So the first time you see a new device,
> it will not get labelled as a multipath path. I assume that one of the paths
> got
> a uevent after the multipath device was created (which does not itself
> trigger a uevent on the path devices). If you delete the devices and re-add
> them, you should now always see two DM_MULTIPATH_DEVICE_PATH=1 lines.

Thanks Ben for your quick relpy!
Confirm the duplicate value isn't problem and change to Verify now.
Comment 12 Ludek Smid 2014-06-13 07:27:48 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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