Re: [PATCH] multipathd: trigger uevents for blacklisted paths in reconfigure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux