| Message ID | 20170902223900.7339-22-mwilck@suse.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | christophe varoqui |
| Headers | show |
On Sun, Sep 03, 2017 at 12:38:50AM +0200, Martin Wilck wrote: > If DM_ACTIVATION is set by the general dm rules, we need to > bring up this device. But if the mpath device is not ready, > that would be dangerous; it could hang or produce lots of IO > errors. So remember this state, and try to activate when the > map becomes usable later. NAK. See reasons in [PATCH 20/31] 11-dm-mpath.rules: don't set READY->ACTIVATION -Ben > > Signed-off-by: Martin Wilck <mwilck@suse.com> > --- > multipath/11-dm-mpath.rules | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/multipath/11-dm-mpath.rules b/multipath/11-dm-mpath.rules > index 3f47744f..9bfd75f8 100644 > --- a/multipath/11-dm-mpath.rules > +++ b/multipath/11-dm-mpath.rules > @@ -4,6 +4,7 @@ ENV{DM_UUID}!="mpath-?*", GOTO="mpath_end" > > IMPORT{db}="DM_DISABLE_OTHER_RULES_FLAG_OLD" > IMPORT{db}="MPATH_DEVICE_READY" > +IMPORT{db}="MPATH_NEEDS_ACTIVATION" > > # If this uevent didn't come from dm, don't try to update the > # device state > @@ -55,6 +56,13 @@ ENV{DM_SUBSYSTEM_UDEV_FLAG0}=="1", ENV{DM_ACTIVATION}="0" > # We'd like to avoid this, especially within udev processing. > ENV{MPATH_DEVICE_READY}=="0", ENV{DM_NOSCAN}="1" > > +# If DM_ACTIVATION is set, but can't be satisfied, remember it > +# in MPATH_NEEDS_ACTIVATION, and activate at the next opportunity. > +ENV{MPATH_DEVICE_READY}=="0", ENV{DM_ACTIVATION}=="1", \ > + ENV{MPATH_NEEDS_ACTIVATION}="1", ENV{DM_ACTIVATION}="0" > +ENV{MPATH_DEVICE_READY}!="0", ENV{MPATH_NEEDS_ACTIVATION}=="1", \ > + ENV{DM_ACTIVATION}="1", ENV{MPATH_NEEDS_ACTIVATION}="" > + > # Also skip all foreign rules if no path is available. > # Remember the original value of DM_DISABLE_OTHER_RULES_FLAG > # and restore it back once we have at least one path available. > -- > 2.14.0 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Hi Ben, On Wed, 2017-09-13 at 16:19 -0500, Benjamin Marzinski wrote: > On Sun, Sep 03, 2017 at 12:38:50AM +0200, Martin Wilck wrote: > > If DM_ACTIVATION is set by the general dm rules, we need to > > bring up this device. But if the mpath device is not ready, > > that would be dangerous; it could hang or produce lots of IO > > errors. So remember this state, and try to activate when the > > map becomes usable later. > > NAK. See reasons in > > [PATCH 20/31] 11-dm-mpath.rules: don't set READY->ACTIVATION Sorry for being slow. Re-reading this, I don't understand any more why your valid argument against 20/31 invalidates this one as well. 21/31 affects only the case MPATH_DEVICE_READY!=0, in which case it will add another case where DM_ACTIVATION is set. Regards Martin > > -Ben > > > > > Signed-off-by: Martin Wilck <mwilck@suse.com> > > --- > > multipath/11-dm-mpath.rules | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/multipath/11-dm-mpath.rules b/multipath/11-dm- > > mpath.rules > > index 3f47744f..9bfd75f8 100644 > > --- a/multipath/11-dm-mpath.rules > > +++ b/multipath/11-dm-mpath.rules > > @@ -4,6 +4,7 @@ ENV{DM_UUID}!="mpath-?*", GOTO="mpath_end" > > > > IMPORT{db}="DM_DISABLE_OTHER_RULES_FLAG_OLD" > > IMPORT{db}="MPATH_DEVICE_READY" > > +IMPORT{db}="MPATH_NEEDS_ACTIVATION" > > > > # If this uevent didn't come from dm, don't try to update the > > # device state > > @@ -55,6 +56,13 @@ ENV{DM_SUBSYSTEM_UDEV_FLAG0}=="1", > > ENV{DM_ACTIVATION}="0" > > # We'd like to avoid this, especially within udev processing. > > ENV{MPATH_DEVICE_READY}=="0", ENV{DM_NOSCAN}="1" > > > > +# If DM_ACTIVATION is set, but can't be satisfied, remember it > > +# in MPATH_NEEDS_ACTIVATION, and activate at the next opportunity. > > +ENV{MPATH_DEVICE_READY}=="0", ENV{DM_ACTIVATION}=="1", \ > > + ENV{MPATH_NEEDS_ACTIVATION}="1", ENV{DM_ACTIVATION}="0" > > +ENV{MPATH_DEVICE_READY}!="0", ENV{MPATH_NEEDS_ACTIVATION}=="1", \ > > + ENV{DM_ACTIVATION}="1", ENV{MPATH_NEEDS_ACTIVATION}="" > > + > > # Also skip all foreign rules if no path is available. > > # Remember the original value of DM_DISABLE_OTHER_RULES_FLAG > > # and restore it back once we have at least one path available. > > -- > > 2.14.0 > >
On Thu, Sep 14, 2017 at 03:06:43PM +0200, Martin Wilck wrote: > Hi Ben, > > On Wed, 2017-09-13 at 16:19 -0500, Benjamin Marzinski wrote: > > On Sun, Sep 03, 2017 at 12:38:50AM +0200, Martin Wilck wrote: > > > If DM_ACTIVATION is set by the general dm rules, we need to > > > bring up this device. But if the mpath device is not ready, > > > that would be dangerous; it could hang or produce lots of IO > > > errors. So remember this state, and try to activate when the > > > map becomes usable later. > > > > NAK. See reasons in > > > > [PATCH 20/31] 11-dm-mpath.rules: don't set READY->ACTIVATION > > Sorry for being slow. Re-reading this, I don't understand any more why > your valid argument against 20/31 invalidates this one as well. 21/31 > affects only the case MPATH_DEVICE_READY!=0, in which case it will add > another case where DM_ACTIVATION is set. If we are always setting DM_ACTIVATION when MPATH_DEVICE_READY changes from zero to non-zero, we don't need to remember that we had to disable DM_ACTIVATION when the device wasn't ready, and make sure to set it now, because we are always setting it when we change to a device ready state... right? -Ben > > Regards > Martin > > > > > -Ben > > > > > > > > Signed-off-by: Martin Wilck <mwilck@suse.com> > > > --- > > > multipath/11-dm-mpath.rules | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/multipath/11-dm-mpath.rules b/multipath/11-dm- > > > mpath.rules > > > index 3f47744f..9bfd75f8 100644 > > > --- a/multipath/11-dm-mpath.rules > > > +++ b/multipath/11-dm-mpath.rules > > > @@ -4,6 +4,7 @@ ENV{DM_UUID}!="mpath-?*", GOTO="mpath_end" > > > > > > IMPORT{db}="DM_DISABLE_OTHER_RULES_FLAG_OLD" > > > IMPORT{db}="MPATH_DEVICE_READY" > > > +IMPORT{db}="MPATH_NEEDS_ACTIVATION" > > > > > > # If this uevent didn't come from dm, don't try to update the > > > # device state > > > @@ -55,6 +56,13 @@ ENV{DM_SUBSYSTEM_UDEV_FLAG0}=="1", > > > ENV{DM_ACTIVATION}="0" > > > # We'd like to avoid this, especially within udev processing. > > > ENV{MPATH_DEVICE_READY}=="0", ENV{DM_NOSCAN}="1" > > > > > > +# If DM_ACTIVATION is set, but can't be satisfied, remember it > > > +# in MPATH_NEEDS_ACTIVATION, and activate at the next opportunity. > > > +ENV{MPATH_DEVICE_READY}=="0", ENV{DM_ACTIVATION}=="1", \ > > > + ENV{MPATH_NEEDS_ACTIVATION}="1", ENV{DM_ACTIVATION}="0" > > > +ENV{MPATH_DEVICE_READY}!="0", ENV{MPATH_NEEDS_ACTIVATION}=="1", \ > > > + ENV{DM_ACTIVATION}="1", ENV{MPATH_NEEDS_ACTIVATION}="" > > > + > > > # Also skip all foreign rules if no path is available. > > > # Remember the original value of DM_DISABLE_OTHER_RULES_FLAG > > > # and restore it back once we have at least one path available. > > > -- > > > 2.14.0 > > > > > > -- > Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
On Fri, 2017-09-15 at 15:40 -0500, Benjamin Marzinski wrote: > On Thu, Sep 14, 2017 at 03:06:43PM +0200, Martin Wilck wrote: > > Hi Ben, > > > > On Wed, 2017-09-13 at 16:19 -0500, Benjamin Marzinski wrote: > > > On Sun, Sep 03, 2017 at 12:38:50AM +0200, Martin Wilck wrote: > > > > If DM_ACTIVATION is set by the general dm rules, we need to > > > > bring up this device. But if the mpath device is not ready, > > > > that would be dangerous; it could hang or produce lots of IO > > > > errors. So remember this state, and try to activate when the > > > > map becomes usable later. > > > > > > NAK. See reasons in > > > > > > [PATCH 20/31] 11-dm-mpath.rules: don't set READY->ACTIVATION > > > > Sorry for being slow. Re-reading this, I don't understand any more > > why > > your valid argument against 20/31 invalidates this one as well. > > 21/31 > > affects only the case MPATH_DEVICE_READY!=0, in which case it will > > add > > another case where DM_ACTIVATION is set. > > If we are always setting DM_ACTIVATION when MPATH_DEVICE_READY > changes > from zero to non-zero, we don't need to remember that we had to > disable > DM_ACTIVATION when the device wasn't ready, and make sure to set it > now, because we are always setting it when we change to a device > ready > state... right? Err... yes. I guess I shouldn't post on udev rule logic after midnight. Sorry. Martin
diff --git a/multipath/11-dm-mpath.rules b/multipath/11-dm-mpath.rules index 3f47744f..9bfd75f8 100644 --- a/multipath/11-dm-mpath.rules +++ b/multipath/11-dm-mpath.rules @@ -4,6 +4,7 @@ ENV{DM_UUID}!="mpath-?*", GOTO="mpath_end" IMPORT{db}="DM_DISABLE_OTHER_RULES_FLAG_OLD" IMPORT{db}="MPATH_DEVICE_READY" +IMPORT{db}="MPATH_NEEDS_ACTIVATION" # If this uevent didn't come from dm, don't try to update the # device state @@ -55,6 +56,13 @@ ENV{DM_SUBSYSTEM_UDEV_FLAG0}=="1", ENV{DM_ACTIVATION}="0" # We'd like to avoid this, especially within udev processing. ENV{MPATH_DEVICE_READY}=="0", ENV{DM_NOSCAN}="1" +# If DM_ACTIVATION is set, but can't be satisfied, remember it +# in MPATH_NEEDS_ACTIVATION, and activate at the next opportunity. +ENV{MPATH_DEVICE_READY}=="0", ENV{DM_ACTIVATION}=="1", \ + ENV{MPATH_NEEDS_ACTIVATION}="1", ENV{DM_ACTIVATION}="0" +ENV{MPATH_DEVICE_READY}!="0", ENV{MPATH_NEEDS_ACTIVATION}=="1", \ + ENV{DM_ACTIVATION}="1", ENV{MPATH_NEEDS_ACTIVATION}="" + # Also skip all foreign rules if no path is available. # Remember the original value of DM_DISABLE_OTHER_RULES_FLAG # and restore it back once we have at least one path available.
If DM_ACTIVATION is set by the general dm rules, we need to bring up this device. But if the mpath device is not ready, that would be dangerous; it could hang or produce lots of IO errors. So remember this state, and try to activate when the map becomes usable later. Signed-off-by: Martin Wilck <mwilck@suse.com> --- multipath/11-dm-mpath.rules | 8 ++++++++ 1 file changed, 8 insertions(+)