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@xxxxxxxx>, 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
