NFS v4.1 or 4.2 mounts pointing to multihomed systems do not appear as expected

This document (000020404) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11

Situation

A NFS client system has two or more mounts pointing to different IP addresses (or hostnames).  However, these IP addresses actually belong to the same remote host (a practice known as mulithoming).  For example, an /etc/fstab may contain:
Server1:/export1   /mnt1   nfs   vers=4.2    0  0
Server2:/export2   /mnt2   nfs   vers=4.2    0  0
"Server1" resolves to 192.168.1.1 and "Server2" resolves to 192.168.1.2.  However, both these IP address are bound to one NFS Server machine.

After the client mounts these, checking a list of current mounts from the "mount" command or from /proc/mounts may show that both show they are using the same hostname and "addr" parameter, even though they were configured different in /etc/fstab:
Server1:/export1 on /mnt1 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Server1:/export2 on /mnt2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Or in some cases (possibly related to the total number of such mounts in question, possibly 3 or more) the data might show all the hostnames one way, but with all the "addr" parameters pointing to the IP that doesn't belong to that name.

Imagine that in addition to the 2 fstab entries above, there is also a 3rd entry, pointing to a 3rd export within the 2nd hostname:
Server2:/export3   /mnt3   nfs  vers=4.2   0 0
The results might be:
Server2:/export1 on /mnt1 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Server2:/export2 on /mnt2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Server2:/export3 on /mnt3 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)

 

Resolution

This is expected behavior for NFS v4.1 and 4.2.
 

Cause

NFS v4.1 and 4.2 include a feature known as "trunking detection" whereby the client detects when two (or more) different addresses lead to the same NFS Server.  In such cases, NFS 4.1 mounts will share connections and resources with other 4.1 mounts, and NFS 4.2 mounts will share with other 4.2 mounts.  This can result in the "addr" parameter of the mount taking effect differently than expected.  Typically, the mount accomplished first will determine which IP address is used for each mount of that version.  However, fstab order does not necessarily determine mount order, because work can be done in parallel.

The name displayed after the fact is determined differently, and may not always match intuitively.  However, this is cosmetic and should not affect functionality.

Additional Information

NFS v3 and v4.0 do not have the "trunking detection" feature.

It is also notable that with SLES 15, NFS client mounts default to v4.2.  In SLES 12, they default to 4.0, and in SLES 11 they default to 3.  Therefore, fstab entries or mount commands which do not specify a version number may suddenly have new behavior after a major upgrade of the OS.

SLES 11 SP4 supports NFS versions up to 4.1, but defaults to 3.
SLES 12 SP4 and SP5 received the addition of support for NFS 4.2, but default to 4.0.
SLES 15 (all SPx) also support up through 4.2, and default to 4.2.

Unlike SLES 12 and 15, SLES 11 doesn't recognize minor versions on the "vers=" parameter.  So instead of "vers=4.1" use "vers=4,minorversion=1".  Both formats are valid on SLES 12 and 15.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000020404
  • Creation Date: 04-Oct-2021
  • Modified Date:04-Oct-2021
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback@suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.


SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center