[dm-devel] [PATCH 14/35] multipathd: add "force_reconfigure" option

[Benjamin Marzinski]

On Thu, Sep 16, 2021 at 09:34:46AM +0200, Martin Wilck wrote:
> On Wed, 2021-09-15 at 19:13 -0500, Benjamin Marzinski wrote:
> > On Fri, Sep 10, 2021 at 01:40:59PM +0200, mwilck at suse.com wrote:
> > > From: Martin Wilck <mwilck at suse.com>
> > > 
> > > Since e3270f7 ("multipathd: use weaker "force_reload" at startup"),
> > > (multipath-tools 0.7.0), we only reload those maps that must be
> > > reloaded during startup. "multipath reconfigure", OTOH, reloads
> > > every map, which may take a long time on systems with lots of
> > > storage devices, as every DM_DEVICE_RELOAD ioctl involves a
> > > suspend/resume cycle.
> > > 
> > > The logic we use during startup is actually very robust and catches
> > > all cases in which a reload is necessary. "reconfigure" operations
> > > are often done because of configuration changes, and usually don't
> > > require a full reload of every map.
> > > 
> > > This patch changes the default behavior of "multipath reconfigure"
> > > to "weak" reload, like we do on startup since e3270f7. The behavior
> > > can be changed by setting the configuration option
> > > "force_reconfigure yes" before starting the reconfigure operation.
> > > "multipath -r" is also affected, but "multipath -D -r" is not.
> > > 
> > > It would have been nice to have introduced a new cli command
> > > "reconfigure force" instead, but the way "reconfigure" is
> > > implemented, that would have required a major rewrite of the code.
> > 
> > This looks o.k. But I don't think it would be that hard to add a new
> > multipathd command to reconfigure all the devices.  My personal
> > preference would be to leave force_reconfigure off by default, so that
> > we keep the same behavior, and add a command to force a full reconfig.
> > I'll try to work up a patch with my idea that can apply on top of this.
> 
> The problem I see is with the "delayed reconfigure" approach. We
> notify child() about a pending reconfiguration by setting
> DAEMON_RECONFIGURE. If clients can request different "types" of
> reconfiguration, we would either need an additional flag, or a new
> state (e.g. DAEMON_RECONFIGURE_FORCE) to indicate which type of
> reconfiguration was requested. And then what to we do if while one
> reconfigure is running, the admin runs both "reconfigure force" and
> "reconfigure"? We can only schedule only one reconfigure operation. We
> should probably assume "force" in that rather unlikely case.

Yeah, that was the plan.

> IMO we should not implement _both_ a configuration option
> "force_reconfigure" _and_ an additional command "reconfigure force". We
> should decide which one we want. If you can come up with a reasonable
> logic for the latter, I agree it's better.

I'm fine with that. I'll send a patch to replace this one, then.

-Ben

> Regards,
> Martin
>