Re: Improve processing efficiency for addition and deletion of multipath devices

From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: Bart@redhat.com, tang.junhui@zte.com.cn, zhang.kai16@zte.com.cn,
	dm-devel@redhat.com, Assche <bart.vanassche@sandisk.com>
Subject: Re: Improve processing efficiency for addition and deletion of multipath devices
Date: Tue, 29 Nov 2016 08:52:17 +0100	[thread overview]
Message-ID: <1480405937.7926.3.camel@suse.com> (raw)
In-Reply-To: <20161128173124.GE1972@octiron.msp.redhat.com>

On Mon, 2016-11-28 at 11:31 -0600, Benjamin Marzinski wrote:
> On Mon, Nov 28, 2016 at 11:28:56AM +0100, Martin Wilck wrote:
> > On Mon, 2016-11-28 at 10:19 +0800, tang.junhui@zte.com.cn wrote:
> > > 
> > > 4.        Proposal 
> > > Other than processing uevents one by one, uevents which coming
> > > from
> > > the 
> > > same LUN devices can be mergered to one, and then uevent
> > > processing 
> > > thread only needs to process it once, and it only produces one DM
> > > addition 
> > > uevent which could reduce system resource consumption. 
> > > 
> > 
> > Here comes an idea how to achieve this without a lot of additional
> > code:
> > 
> > libmultipath already has code to check whether any maps need to be
> > updated (in coalesce_paths()). Instead of recording uevents,
> > merging
> > them, and calling ev_add_path() for every affected WWID, it might
> > be
> > sufficient to set daemon state to DAEMON_CONFIGURE and wake up the
> > main
> > multipathd thread to call reconfigure(). Then we only need to make
> > sure
> > that coalesce_paths() really reloads or creates maps only when
> > necessary. I have some patches here that I made for that purpose,
> > for a
> > different scenario (multipathd to avoid RELOAD ioctls when it's
> > started
> > in a scenario where most paths are already set up by udev).
> 
> There is a long standing multipath issue that this will likely make a
> lot worse.  Currently, multipathd can drop paths that it doesn't have
> access to on reconfigure. This is wrong. When the path comes back, it
> won't issue another add uevent. This means that multipathd won't be
> able
> to re-enable it (since it stopped monitoring it during the
> reconfigure).
> In fact the only way to get the path back is to either manually
> intervene or to have the path actually get removed from the system
> and
> come back.

Thanks for pointing this out. But don't you think it can be dealt with
by fixing the reconfigure() path? 

My point is: any code that merges uevents and tries to figure out the
correct "minimal" set DM operations to put the changes in place re-
implement at least parts of the logic of coalesce_paths(), and face
similar problems.

Regards
Martin

-- 
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