Bug#827322: multipath-tools: Not all paths discovered when large number of paths are present
Andrew Patterson
andrew.patterson at hpe.com
Wed Jun 15 17:12:39 UTC 2016
On 06/15/2016 08:43 AM, Ritesh Raj Sarraf wrote:
> Control: tag -1 moreinfo
>
> On Tue, 2016-06-14 at 17:30 -0600, Andrew Patterson wrote:
>> There is no output in dmesg.
>>
>> Changing /proc/sys/fs/aio-max-nr from the default 65536 to 1048576
>> seems to help. With this change, I can go up to 256 LUNs (1024 paths)
>> with no problems.
>>
>> I have seen similar issues in earlier versions of multipath-tools.
>
> Thank you for bringing this up, and the pointer. In multipath.conf there was a
> directive added for something similar.
>
>
> max_fds Specify the maximum number of file descriptors that
> can be opened by multipath and multipathd. This is
> equivalent to ulimit -n. A value of max will set this
> to the system limit from /proc/sys/fs/nr_open. If this
> is not set, the maximum number of open fds is taken
> from the calling process. It is usually 1024. To be
> safe, this should be set to the maximum number of
> paths plus 32, if that number is greated than 1024.
>
>
> It seems to be inline with what aio-max-nr documentation says.
>
> ==============================================================
>
> aio-nr & aio-max-nr:
>
> aio-nr is the running total of the number of events specified on the
> io_setup system call for all currently active aio contexts. If aio-nr
> reaches aio-max-nr then io_setup will fail with EAGAIN. Note that
> raising aio-max-nr does not result in the pre-allocation or re-sizing
> of any kernel data structures.
>
> ==============================================================
>
>
> Have you tried it with the "max_fds" option set ?
>
>
Thanks for reminding me about max_fds. At boot:
# cat /proc/sys/fs/nr_open
1048576
and
# multipath -t | grep max_fds
max_fds "max"
So this should already be set to 1048576. I tried the test again after
setting max_fd 1048576 in /etc/multipath.conf and got the same
behavior.
--
Andrew Patterson
Hewlett-Packard Enterprise
More information about the pkg-lvm-maintainers
mailing list