Bug#827322: multipath-tools: Not all paths discovered when large number of paths are present

[Andrew Patterson]

On Thu, 16 Jun 2016 15:19:22 +0530 Ritesh Raj Sarraf <rrs at debian.org> wrote:
> Control: tag -1 +pending
> 
> On Wed, 2016-06-15 at 13:03 -0600, Andrew Patterson wrote:
> > For most users this is not an issue. How many systems are going to use
> > that many LUNs?
> > 
> 
> I agree.
> 
> > One counter-example is using one or more FC LUNs per VM guest on a
> > host. In such a case, one can just modify /etc/sysctl.conf to increase
> > the setting. 
> 
> Yes. Most hypervisors may want this. But again, like you said, most users do not
> map that many LUNs. And recommended practice is to have a VM backed by a file
> backend mostly.


OpenStack/cinder can (and is) be uses to provision VMs with networked
drives. It is pretty common for cloud applications.  I don't know what
a practical limit for the number of volume per VMs per host should be.


> 
> > We can run into problems when using
> > multipath-tools-boot. In this case, we use the default kernel settings
> > for aio-max-nr since multipath is run from the initramfs. I have
> > worked around this by modifying the script in
> > /usr/share/initramfs/scripts/local-top/multipath to temporarilly set
> > aio-max-nr to 1048576 while doing discovery.
> 
> 
> So, I'll just add this to README.Debian. There's not much that we can do beyond
> documenting such behavior.

I will work on patch to have a user-configurable setting of aio-max-nr
in the initramfs. You can then decide if it is worth it to apply it.

In the meantime, the README.Debian change sounds fine to me.

-- 
Andrew Patterson
Hewlett-Packard Enterprise