On Mon, Feb 13, 2017 at 04:46:07PM +0100, Peter Rajnoha wrote:
> 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.
You're right. I'll change this.
Thanks.
-Ben
>
> --
> Peter
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
