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

On Mon, 2026-06-15 at 10:56 -0400, Benjamin Marzinski wrote:
> 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.

That would be a welcome addition to Xose's set, then.

> 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.

I see that it's possible. Assigning weights only as sort of a sort key
for path grouping appears somewhat non-obvious and over-complicated to
me. But fair enough, some people may use it this way indeed.

Martin