[dm-devel] [PATCH 0/4] Add "reconfigure all" multipath command

[Martin Wilck]

On Mon, 2021-09-27 at 10:11 -0500, Benjamin Marzinski wrote:
> On Fri, Sep 24, 2021 at 10:44:46PM +0200, Xose Vazquez Perez wrote:
> > On 9/21/21 01:21, Benjamin Marzinski wrote:
> > 
> > > This patchset is supposed to replace Martin's
> > > 
> > > multipathd: add "force_reconfigure" option
> > > 
> > > patch from his uxlsnr overhaul patchset. It also makes the
> > > default
> > > reconfigure be a weak reconfigure, but instead of adding a
> > > configuration
> > > option to control this, it adds a new multipathd command,
> > > "reconfigure all", to do a full reconfigure. The HUP signal is
> > > left
> > > doing only weak reconfigures.
> > > In order to keep from having two states that are handled nearly
> > > identically, the code adds an extra variable to track the type of
> > > configuration that was selected, but this could easily be switch
> > > to
> > > use a new DAEMON_CONFIGURE_ALL state instead.
> > > The final patch, that added the new command, is meant to apply on
> > > top of
> > > Martin's changed client handler code. I can send one that works
> > > with the
> > > current client handler code, if people would rather review that.
> > 
> > This change is going to affect some places, raw search:
> 
> Yes. I specifically broke the code that actually changes how
> multipathd
> operates from a user' point of view into a seperate patch (4/4)
> because
> distributions might need to revert in, if they want to pull in recent
> upstream changes, but don't what this kind of change in multipathd's
> behavior.
> 
> I admit, this patchset needs to include documentation to mention the
> changed behavior. I'll add that. 

Well, the idea is that there is actually no difference between "weak"
and "hard" reconfigure in terms of the end result. If a change must be
applied to reconcile kernel state and user settings, "weak" reconfigure
will do it. The documentation should express that and avoid stipulating
doubt among users. The main difference is that "hard" reconfigure
always executes a reload operation, which comes down to a
suspend/reload/resume, and thus a) is slow and b) unnecessarily
interrupts IO on the map for a few fractions of a second.

My personal PoV is that we should consider it a bug if a user reports a
situation where a "hard" reconfigure has a different outcome than a
"weak" one. Of course distros need to think twice when any defaults
change, and therefore the way Ben split the patch set makes a lot of
sense. Yet if we had serious doubts that "weak" reconfigure works, we
shouldn't switch to it upstream, either. I personally don't have such
doubts any more. Xose, if I'm missing something, let me know.

Cheers,
Martin