I think we should actually introduce a new return code. - DMP_NOT_FOUND should actually mean that the given map does not exist at all - DMP_NO_MATCH should mean that it has targets that don't match (either multiple targets, or something non-multipath), or that the UUID doesn't match (if MAPINFO_CHECK_UUID is set). - We should have another rc code for "exists but is empty", but that should be called DMP_EMPTY rather than DMP_BAD_DEV. > On the other hand, there is still a window where the program that we > raced with is in the middle of creating the device, but it doesn't > have > a live table yet. In this case, even the DMP_BAD_DEV code won't be > able > to distinguish between a map that didn't get created correctly and > one > that is in the process of getting created. It would reduce the window > where we could accidentally delete a working device, however. I wouldn't bother about this kind of race too much. If multipathd just ignores this kind of maps as it used to, it won't do any harm AFAICT. We shouldn't alter this behavior, IOW multipathd should neither remove these maps nor add them to its internal tables unless they become populated with paths. If anything, we should finally get down to delegating map creation from multipath to multipathd. > Since it doesn't add much complexity, I lean towards keeping it, but > it > is one more state we need to handle on returns from libmp_mapinfo(), > so > I'm open to an argument that it's not worth it. I agree, comments above. > > > The only issue with the current code is that if you have a device > > > with > > > no table with the UUID of a multipath device but a different name > > > than > > > that multipath device should have, multipath will try to create a > > > new > > > device instead of reload it, and this fails, since the UUID is > > > already > > > in use. > > > > That should be handled in coalesce_paths(). It's basically the > > scenario > > that occurs if we enable or disable user_friendly names. > > Except that we have a mpp for the other device if it has a table. If > the > device doesn't have a table, then a mpp isn't created, so > coalesce_paths() doesn't track it. We could add code to create mpps > for > these tableless devices, but it's another trade off of added > complexity > to handle a rare corner case, and I'm not sure this one is worth it. What I meant is that if there are matching path devices, coalesce_paths() will create an mpp and reload the table. Otherwise, the table will continue lurking around without being tracked, which doesn't do harm even if it may not seem optimal. If a matching path is added, again, uev_add_path() should reload the map (to be tested). I think that behavior is sane enough for a corner case like this. Martin
