[dm-devel] [PATCH 7/7] fix udev rules for failed multipath devices

[Benjamin Marzinski]

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