Re: [PATCH 1/3] multipath-tools: delete obsolete information from multipath.conf.5

[Benjamin Marzinski <bmarzins@redhat.com>]

On Mon, Jun 15, 2026 at 11:11:07AM +0200, Martin Wilck wrote:
> On Sun, 2026-06-07 at 12:38 +0200, Xose Vazquez Perez wrote:
> > repeat_count (rr_min_io, rr_min_io_rq, rr_weight) has been
> > unsupported
> > since kernel 4.6 ( commits 90a4323ccfea and  21136f89d76d ).
> > 
> 
> I can't make up my mind on this patch. It is true that most path
> selectors in the kernel have ignored the repeat_count argument
> for a long time (historical_service_time still seems to honour it).
> 
> But this is multipath-tools. _We_ still have quite a bit of code for
> handling the minio and weight settings. We should add a hint the the
> man page that these settings are ignored by modern kernels, but it
> would be simply wrong to say that _our_ code ignores them while it
> doesn't. 
> 
> We can decide to remove this functionality from multipath-tools, which
> would obviously mean removing it from the man page as well. But if we
> do, we should apply further cleanups. I suppose that providing the
> "weightedpath" prioritizer makes no sense if we have no path selector
> algorithm that takes such weights into account, for example.
> 
> I should also note that there have been discussions with some partners
> about re-introducing parameterized path selectors. This was a topic in 
> the context of Fibre Channel FPIN notifications: FPINs can be used by
> FC fabric to notify hosts about overloaded paths. With a parameterized
> path selector, the load on such paths could be decreased by multipathd.
> temporarily until the situation is normal again. While there has been
> little progress in this area, I don't consider it cast in stone that
> the kernel will keep ignoring path selector parameters forever, or IOW,
> that there won't be new path selectors in the future that do accept
> path parameters again.
> 
> No doubt that the way these parameters are interpreted in different
> ways ("minio" vs. "weight" vs "repeat_count") and the way this is
> exposed to end users in the configuration file and in the man page is
> broken and confusing. But fixing that would be a larger effort.

I actually do have a patch set I'm testing that rips out the rr_weight
and rr_min_io_rq code completely. It leaves the rr_min_io functionality
(on the grounds that we many have a use for it later), but it now
defaults to 1 and is deprecated, so it can't be changed. I assume that
even if this code gets reused in the future, rr_min_io will remain a
bad name for the option.

I feel like the weightedpath priortizer shouldn't be effected by this.
It is still useful to manually assign paths to path_groups when combined
with group_by_prio.

-Ben

> 
> Regards
> Martin