[dm-devel] [PATCH v3 17/20] multipath -u: test if path is busy

[Martin Wilck]

On Fri, 2018-04-13 at 10:53 -0500, Benjamin Marzinski wrote:
> On Fri, Apr 13, 2018 at 12:17:54AM +0200, Martin Wilck wrote:
> > 
> > As I said already, I don't understand why you say that.
> > 
> > I can assert that if is_failed_wwid() returns true, multipathd has
> > definitely tried and failed since the last reboot, and no (other
> > instance of) multipathd or multipath has succeeded since then.
> > 
> > If is_failed_wwid() returns false, it's possible that the map
> > already
> > exists (see patch 18), or that previous/current instances of
> > multipathd
> > simply didn't try -  we have to check by other means.
> 
> I probably shouldn't have brought up is_failed_wwid() up here at all.
> It has really nothing to do with my main point.
> 
> But just to rehash this again, you do agree that multipathd can get a
> uevent for for a path device, recognize that it should create a
> multipath device on it, and then fail somewhere in ev_add_path before
> it
> get around to calling domap, right? If this happens, multipathd won't
> automatically try to create that device again until either it gets
> another add event for a path in that device, or it is
> reconfigured.  In
> this case the is_failed_wwid() result would make it seem like
> multipathd
> might still be waiting to create this device, when in truth, that
> won't
> happen.

I agree. (is_failed_wwid(refwwid) != WWID_IS_FAILED) doesn't really
mean a lot, it happens in many different situations. Luckily we test
only for (is_failed_wwid(refwwid) == WWID_IS_FAILED), which is well-
defined, and make further checks otherwise.

Regards
Martin

-- 
Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)