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