On Fri, 2024-11-08 at 17:08 -0500, Benjamin Marzinski wrote: > On Thu, Nov 07, 2024 at 07:02:11PM +0100, Martin Wilck wrote: > > On Thu, 2024-11-07 at 12:43 -0500, Benjamin Marzinski wrote: > > > On Thu, Nov 07, 2024 at 01:20:09PM +0100, Martin Wilck wrote: > > > > > > > > Thinking about it, I believe we should actually accept devices > > > > that > > > > have an mpath UUID and an empty table, and add them to our > > > > mpvec. > > > > We > > > > should treat them like devices that have a multipath target but > > > > no > > > > path > > > > devices. If any matching paths become available, the map will > > > > be > > > > reloaded and the issue will be fixed. IMO, this is less prone > > > > to > > > > race > > > > conditions than trying to delete and re-add the devices. > > > > > > I'm not sure off the top of my head how easy it will be to handle > > > devices with no dm table at all, but I'll take a look into this. > > > > I tried this on a system with 0.9.9 yesterday. 0.9.9 will not add > > the > > map into the mpvec. But in coalesce_paths(), it will just reload > > the > > map: > > Given that the code already does the right thing without needing any > changes to handle tableless maps makes me feel like just removing the > final patch is the best idea. If we do this, do we still need the special case for DMP_BAD_DEV? IMO we just need to make sure that dm_get_maps() doesn't return an error if it encounters an empty map. > 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. > That should probably be handled by making the multipath code pay more > attention to the device UUID and less to the device name, but that's > work for a different patchset. Yes, definitely. Martin
