On 02/11/2017 06:28 AM, Benjamin Marzinski wrote:
> diff --git a/multipath/11-dm-mpath.rules b/multipath/11-dm-mpath.rules
> index 5559af3..b253433 100644
> --- a/multipath/11-dm-mpath.rules
> +++ b/multipath/11-dm-mpath.rules
> @@ -2,39 +2,66 @@ ACTION!="add|change", GOTO="mpath_end"
> ENV{DM_UDEV_RULES_VSN}!="?*", GOTO="mpath_end"
> ENV{DM_UUID}!="mpath-?*", GOTO="mpath_end"
>
> +IMPORT{db}="DM_DISABLE_OTHER_RULES_FLAG_OLD"
> +IMPORT{db}="MPATH_DEVICE_READY"
> +
> +# If this uevent didn't come from dm, don't try to update the
> +# device state
> +ENV{DM_ACTIVATION}!="1", DM_ACTION!="?*", IMPORT{db}="DM_UDEV_DISABLE_OTHER_RULES_FLAG", IMPORT{db}="DM_NOSCAN", GOTO="scan_import"
> +
...
> +# This event is either a PATH_REINSTATED or a table reload where
> +# there are active paths. Mark the device ready
> +ENV{MPATH_DEVICE_READY}=""
> +
If we're doing coldplug (the "udevadm trigger --action=add" or "echo add
> /sys/block/<devname>/uevent"), I think this will drop any existing
MPATH_DEVICE_READY="0" here. Thing is that the ENV{DM_ACTIVATION}="1" is
also set for the coldplug case which generates spurious events, not only
for uevents coming from DM directly.
What we can do though is that we can check for DM_COOKIE and
DM_ACTION="PATH_*" variable existence in which case the uevent surely
comes from DM/mpath driver directly from kernel, so we can rule out the
coldplug case with spurious events.
--
Peter
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
