On Sun, 2020-07-19 at 00:12 -0500, Benjamin Marzinski wrote: > On Thu, Jul 09, 2020 at 12:51:37PM +0200, mwi...@suse.com wrote: > > From: Martin Wilck <mwi...@suse.com> > > > > Treat this like a WWID mismatch. > > > > Signed-off-by: Martin Wilck <mwi...@suse.com> > > --- > > libmultipath/structs_vec.c | 37 +++++++++++++++++++++++----------- > > --- > > 1 file changed, 23 insertions(+), 14 deletions(-) > > > > diff --git a/libmultipath/structs_vec.c > > b/libmultipath/structs_vec.c > > index 5dd37d5..8651b98 100644 > > --- a/libmultipath/structs_vec.c > > +++ b/libmultipath/structs_vec.c > > > > [...] > > + bad_path: > > + /* > > + * This path exists, but in the wrong map. > > + * We can't reload the map from here. > > + * Instead, treat this path like "missing > > udev". > > + * check_path() will trigger an uevent and > > reset pp->tick. > > + */ > > + must_reload = true; > > + pp->mpp = NULL; > > + dm_fail_path(mpp->alias, pp->dev_t); > > + vector_del_slot(pgp->paths, j--); > > + pp->initialized = INIT_MISSING_UDEV; > > + pp->tick = 1; > > Is there a reason not to call orphan_path() to clean up things like > any > open fd, until we figure out what to do with the path.
Thanks for the suggestion. It makes sense for the 2nd "bad_path" condition but not for the first. I'll treat the two cases differently. Regards Martin -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
