On Thu, 2023-09-07 at 15:33 +0200, Martin Wilck wrote: > On Thu, 2023-09-07 at 09:24 +0200, Martin Wilck wrote: > > On Wed, 2023-09-06 at 17:42 -0500, Benjamin Marzinski wrote: > > > On Fri, Sep 01, 2023 at 08:02:17PM +0200, mwilck@xxxxxxxx wrote: > > > > > > > > > Again, unless I'm overlooking something, I don't think we need to > > > check if the alias is already taken here. Since we know that a > > > device > > > already exists with alias_old and the correct WWID, as long as > > > alias_old > > > is a valid user_friendly_name we can just use it. > > > > Similar reasoning as above. We could perhaps remove these checks, > > but > > we'd need to replace them by comments explaining why this condition > > can't occur. > > > > We could (and maybe should) move the call to find_existing_alias() > > from > > add_map_with_path() to get_user_friendly_alias(), so that we have > > the > > entire alias logic in a single place. The mpp->alias_old field > > would > > then only be used for ACT_RENAME. > > Well, if we do this, we would need to pass vecs->mpvec to > get_user_friendly_alias(), which means that we could use it also for > the alias_already_taken() check. It's not exactly the same because in > one case we look at internal state and in the other case at kernel > state. OTOH, we do trust that the two are in agreement, right? And we > derive alias_old from the mpvec today, anyway. Ok, this doesn't work. The kernel device mapper mandates no naming conventions for map aliases / names, except that they're unique. The mpvec contains only aliases of multipath maps. But it's not forbidden that some non-multipath map be called "mpathc". OTOH, if we have positive evidence that a given WWID has an alias mpathX assigned, we do know that no other map can have this same name. It just comes down to whether we trust the mpvec to correctly represent kernel state, and I suppose we have to, anyway. Sorry for the spam. I'll just remove these these checks, and the corresponding test cases. Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
