Re: [PATCH] multipath-tools: add more info about max_sectors_kb in multipath.conf.5

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

 



On Sat, 2021-03-06 at 16:30 +0100, Xose Vazquez Perez wrote:
> Change of the default value in the kernel:
>  
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d2be537c3ba35
> 
> To query the device:
> sg_inq -p 0xb0 /dev/sdX | grep "[ml] transfer length:"
> 
> 
> Note: some arrays does not report any value.
>       3PAR: 65534 blocks
>       RDAC: not reported
>       Hitachi VSP: query error
> 
> Cc: Martin Wilck <mwilck@xxxxxxxx>
> Cc: Benjamin Marzinski <bmarzins@xxxxxxxxxx>
> Cc: Christophe Varoqui <christophe.varoqui@xxxxxxxxxxx>
> Cc: DM-DEVEL ML <dm-devel@xxxxxxxxxx>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@xxxxxxxxx>
> ---
>  multipath/multipath.conf.5 | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
> index 8ef3a747..21963813 100644
> --- a/multipath/multipath.conf.5
> +++ b/multipath/multipath.conf.5
> @@ -1240,9 +1240,11 @@ The default is: \fB0\fR
>  .B max_sectors_kb
>  Sets the max_sectors_kb device parameter on all path devices and the
> multipath
>  device to the specified value.
> +If the storage device(array, hard disk, ...) does not export the
> value to the
> +system, the kernel sets it to 512(kernel < 4.3) or 1024(kernel >=
> 4.3).

I don't think this information belongs into the multipath.conf(5) man
page. We shouldn't start documenting changes of kernel defaults in this
man page, unless we intend to continue doing so and keep the
information up-to-date, and I don't think we can promise that. Also,
the kernel major/minor number information may easily be wrong for
distribution kernels that have backported the respective change. Kernel
behavior should be documented in the kernel documentation as provided
by the distribution.

The way the kernel handles max_sectors and max_hw_sectors is actually
pretty complex, and I wouldn't even attempt to try and explain it in
this man page.

That said, what's actually important for users to realize is the fact
that changes of max_sectors_kb don't propagate up the storage stack.
Once a DM device is first created, it will inherit the max_sectors_kb
value of the dm target(s). But if the value is changed for low-level
devices later, upper-level devices won't see the change. A typical
mistake is to run an udev rule decreasing max_sectors_kb for a SCSI
device after a multipath map has already been set up on that SCSI
device (e.g. in the initrd). The  multipath map will have a larger
max_sectors_kb value than the path device, and IO may actually fail for
that reason.

Thus it's generally recommended to use multipath.conf for applying
max_sectors_kb changes. If other devices (e.g. LVM) are stacked on top
of multipath, the same reasoning applies; therefore max_sectors_kb
shouldn't be changed at runtime without double-checking the entire
storage stack.

Regards,
Martin

>  .RS
>  .TP
> -The default is: \fB<device dependent>\fR
> +The default is: \fB<device dependent>\fR, or kernel provided if
> there is no value.




--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel





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

  Powered by Linux