On Fri, 2025-05-09 at 13:28 +0200, Xose Vazquez Perez wrote: > Cc: Martin Wilck <mwi...@suse.com> > Cc: Benjamin Marzinski <bmarz...@redhat.com> > Cc: Christophe Varoqui <christophe.varo...@opensvc.com> > Cc: DM-DEVEL ML <dm-devel@lists.linux.dev> > Signed-off-by: Xose Vazquez Perez <xose.vazq...@gmail.com> > --- > multipath/multipath.conf.5.in | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/multipath/multipath.conf.5.in > b/multipath/multipath.conf.5.in > index d0f6c6ac..9884df93 100644 > --- a/multipath/multipath.conf.5.in > +++ b/multipath/multipath.conf.5.in > @@ -197,22 +197,25 @@ kernel multipath target: > .RS > .TP 12 > .I "round-robin 0" > -Loop through every path in the path group, sending the same amount > of I/O to > -each. Some aspects of behavior can be controlled with the > attributes: > -\fIrr_min_io\fR, \fIrr_min_io_rq\fR and \fIrr_weight\fR. > +Choose the path for the next bunch of I/O based on a rotational > distribution,
"rotational distribution" sounds weird. "by looping through every path in the path group" is easier to understand. > +sending \fBthe same number of I/Os\fR to each path. Some aspects of > behavior can be > +controlled with the attributes: \fIrr_min_io\fR, \fIrr_min_io_rq\fR > and \fIrr_weight\fR. > .TP > .I "queue-length 0" > -(Since 2.6.31 kernel) Choose the path for the next bunch of I/O > based on the amount > -of outstanding I/O to the path. > +(Since 2.6.31 kernel) Choose the path for the next bunch of I/O > based on \fBthe lowest > +number of outstanding in-flight I/Os\fR to the path. I suggest using "I/O requests" rather than "I/Os". > .TP > .I "service-time 0" > -(Since 2.6.31 kernel) Choose the path for the next bunch of I/O > based on the amount > -of outstanding I/O to the path and its relative throughput. > +(Since 2.6.31 kernel) Choose the path for the next bunch of I/O > based on \fBthe > +lowest total size (in bytes) of outstanding in-flight I/Os\fR to the same as above, or use "in-flight I/O". > path. If > +\fIrelative_throughput\fR argument is defined for each path, it's > also used to > +calculate the best service time. This is misleading, as multipath-tools currently don't support path weights, except for round-robin. > .TP > .I "historical-service-time 0" > -(Since 5.8 kernel) Choose the path for the next bunch of I/O based > on the > -estimation of future service time based on the history of previous > I/O submitted > -to each path. > +(Since 5.8 kernel) Choose the path for the next bunch of I/O with > \fBa dinamyc Typo. > +algorithm based on the historical service time and the number > outstanding > +in-flight I/Os\fR to the path. It can be tuning with See above wrt "I/Os". Also, use "tuned" ... > \fIbase_weight\fR and > +\fIthreshold_multiplier\fR arguments. > .TP > The default is: \fBservice-time 0\fR > .RE ... but again, this is misleading. As the trailing "0" implies, multipath-tools currently doesn't support passing parameters to path selector algorithms. In the multipath.conf man page, we shouldn't mention features that we don't support. Regards Martin
