On Fri, 2025-01-24 at 16:05 -0500, Benjamin Marzinski wrote: > On Thu, Jan 23, 2025 at 11:12:12PM +0100, Martin Wilck wrote: > > If multipathd has already configured maps, and the user changes the > > blacklist or other parameters that cause currently multipathed > > devices to be skipped, and then runs "multipathd reconfigure" > > or restarts multipathd, multipathd flushes the maps in question, > > but doesn't trigger uevents for the now-blacklisted paths. > > > > This is because the blacklisted paths are removed from the > > discovered > > maps internally when update_pathvec_from_dm() is called through > > map_discovery() and update_multipath_table(); when later > > trigger_paths_udev_change() is called from coalesce_maps(), the > > map contains no paths for which an uevent could be triggered. > > > > The map_discovery() code flow is special, because we will call > > coalesce_paths() afterwards anyway and reconstruct the mpvec. > > Unlike the > > regular code flow, we don't want the maps to be "corrected" in this > > case, because the maps discovered here aren't going to be reloaded. > > We just want update_pathvec_from_dm() to populate the pathvec. > > > > Therefore add a new flag DI_DISCOVERY, which is only set when > > update_multipath_table() is called from map_discovery(), and if > > this flag is set, keep PATHINFO_SKIPPED paths in the map's table in > > update_pathvec_from_dm(). Later on, the paths will still be visible > > in the old mpp (ompp) in coalesce_maps(), and uevents will be > > triggered for them to release them to systemd. > > > > We can't always do this for PATHINFO_SKIPPED, because in some cases > > paths may be accepted in a map first and SKIPPED later (for example > > if > > the WWID wasn't yet available at startup). Therefore the special > > case for DI_DISCOVERY is necessary. > > > > Signed-off-by: Martin Wilck <mwilck@xxxxxxxx> > > Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx> Thanks ... I just realized that this patch doesn't apply on "queue" because I had written it on top of some other work I was doing on my "tip" branch. It can be easily rebased though. Martin