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.

*** Bug 877256 has been marked as a duplicate of this bug. ***

I've committed the attached patch.

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?

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.

(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.

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.

(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.

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.