Re: [PATCH 12/22] multipathd: adjust when mpp is synced with the kernel

[Benjamin Marzinski <bmarzins@redhat.com>]

On Mon, Jul 15, 2024 at 06:23:53PM +0200, Martin Wilck wrote:
> On Sat, 2024-07-13 at 02:04 -0400, Benjamin Marzinski wrote:
> > Move the code to sync the mpp device state into a helper function and
> > add a counter to to make sure that the device is synced at least once
> > every max_checkint secs. This makes sure that multipath devices with
> > no
> > paths will still get synced with the kernel.  Also, if multiple paths
> > are checked in the same loop, the multipath device will only be
> > synced
> > with the kernel once, since every time the mpp is synced in any code
> > path, mpp->sync_tick is reset.
> > 
> > The code still syncs the mpp before updating the path state for two
> > main reasons.
> > 
> > 1. Sometimes multipathd leaves the mpp with a garbage state. Future
> >    patches will fix most of these cases, but the code intentially
> >    does not remove the mpp is resyncing fails while checking paths.
> >    But this does leave the mpp with a garbage state.
> > 
> > 2. The kernel chages the multipath state independently of multipathd.
> > If
> >    the kernel fails a path, a uevent will arrive shortly. But the
> > kernel
> >    doesn't provide any notification when it switches the active
> >    path group or if it ends up picking a different one than
> > multipathd
> >    selected. Multipathd needs to know the actual current pathgroup to
> >    know when it should be switching them.
> > 
> > Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
> > ---
> >  libmultipath/configure.c   |  1 +
> >  libmultipath/structs.h     |  2 ++
> >  libmultipath/structs_vec.c |  5 +++
> >  multipathd/main.c          | 64 +++++++++++++++++++++++++-----------
> > --
> >  4 files changed, 50 insertions(+), 22 deletions(-)
> > 
> > 
> > diff --git a/multipathd/main.c b/multipathd/main.c
> > index fbd253ca..179fec24 100644
> > --- a/multipathd/main.c
> > +++ b/multipathd/main.c


> > @@ -2752,12 +2767,17 @@ checkerloop (void *ap)
> >  		while (checker_state != CHECKER_FINISHED) {
> >  			unsigned int paths_checked = 0, i;
> >  			struct timespec chk_start_time;
> > +			struct multipath *mpp;
> >  
> >  			pthread_cleanup_push(cleanup_lock, &vecs-
> > >lock);
> >  			lock(&vecs->lock);
> >  			pthread_testcancel();
> > +			vector_foreach_slot(vecs->mpvec, mpp, i)
> > +				mpp->is_checked = false;
> 
> Why is this not done inside the "if (checker_state == CHECKER_STARTING)
> code path?

Since we slept here, there was more time for something to change in a
way where we needed to resync the state. Also, like I mention in the
comments, there are places where we fail in some function that is
updating the mpp state and don't resync it with the kernel. I'm fairly
sure (but not totally certain) future patches catch all of these except
for failing to update the state in the checker function itself. (We've
never removed the multipath device for failing to resync its state in
the check_path(), unlike failures when responding to an event or after
reloading the device. This makes sense to me. Since we're doing these
resyncs in check_path() routinely, not because we think something has
changed, it seems reasonable to assume that nothing has changed if we
fail to resync).

Clearing is_checked here doesn't guarantee that we will resync the mpp.
Only that we will resync if we need to check one of its paths, after the
interruption. When we switch to checking paths by mpp later, this will
never happen, except in corner cases.

-Ben 

> Martin
> 
> 
> >  			get_monotonic_time(&chk_start_time);
> >  			if (checker_state == CHECKER_STARTING) {
> > +				vector_foreach_slot(vecs->mpvec,
> > mpp, i)
> > +					check_mpp(vecs, mpp, ticks);
> >  				vector_foreach_slot(vecs->pathvec,
> > pp, i)
> >  					pp->is_checked = false;
> >  				checker_state = CHECKER_RUNNING;