Explanation of NFS mount options: nconnect=, nosharetransport, sharetransport=

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12

When a Linux machine executes an NFS-over-TCP mount for one or more NFS shares from an individual NFS server, the traditional behavior is that all those mounts share one TCP connection if they are using the same NFS protocol version.  In cases of high NFS work load at the client, this connection sharing may result in lower performance or unnecessary bottlenecks.  To expand and manage NFS usage of TCP connections, SUSE has introduced various different client mount options over time, and these have culminated in an upstream (Linux-wide) option.

This document will discuss three different mount options and their usage.  They are intended to be MUTUALLY EXCLUSIVE, i.e. not used at the same time at one client, for the same group of mounts.
 

nconnect=<value>

The nconnect mount option exists in all Linux distributions (not just SUSE) with kernel 5.3 or higher.  It has also been back-ported into SUSE's 4.12.14 kernels.  Thus, it is present in SLES 12 SP4 and SP5, and all levels of SLES 15.

It can be used with NFS v2, v3, and all v4.x variants, with each individual version (including any minor version) being tracked separately.

Usage:   nconnect=<value> should be set to a number from 1 to 16 (inclusive).  This will set the number of TCP connections which the client will form between itself and the NFS server, to handle all NFS work for that version of the NFS protocol.

This setting will only take effect during the client's first mount for that particular NFS server/version combination.  If the client executes another NFS mount for the same NFS server/version, it will join in sharing whatever connections were established by the first mount.  Subsequent mount commands cannot override the nconnect value already established.  To set a new nconnect value, all of a client's mounted NFS file systems which point to a certain NFS server/version must be umounted, and then the first NFS file system to be remounted must set the desired nconnect value.

If nconnect is not specified during the first mount, then "nconnect=1" is assumed, which results in the same traditional behavior described in the Situation section above.

"mount" output and /proc/mounts contents will show the real "nconnect=<value>" in effect, with the exception that it will not show "nconnect=1" unless "nconnect=1" was explicitly specified when the mount was executed.

Although nconnect can cause many connections to open initially, they can be closed and reopened later as needed.  Thus, the number of active connection which can be confirmed through netstat or other means may sometimes be less than the nconnect value.
 

nosharetransport

The nosharetransport mount option was introduced in SLES 11 SP2 and is still present up through SLES 12 SP5.  It has been removed as of SLES 15.

It applies to NFS v2 and v3.

Usage:  nosharetransport will cause a mount to use its own isolated TCP connection.  It will not share its TCP connection with any other mount done before or after.
 

sharetransport=<value>

The sharetransport=n mount option exists in all SLES 12 releases.  It has been removed as of SLES 15.

It applies to NFS v4.x, with each minor version being tracked independently.

Usage:  sharetransport=<value> uses a numeric value, but this does not represent a number of connections. Rather, it is an arbitrary number that is used as a guide to determine which mounts will share their TCP connection.  If two (or more) mounts of a certain NFS server/version have used the same sharetransport value, those mounts will share one TCP connection.  Mounts with different sharetransport values will use a different connection.  Mounts of a certain NFS server/version which do not set any sharetransport value will share one connection with each other.

Within Linux code, the introduction of these options impacted NFS client code only, as these options do not rely on any NFS server behavior that was not already present and defined by RFC.  However, it is possible that some non-Linux NFS servers with incomplete implementations may not be prepared for the use of "nconnect" or may need updates.  For example, NetApp documentation for ONTAP 9 indicates that ONTAP 9.8 is needed to support clients using nconnect with NFS v4.1.

Please note that these options are not intended to result in any significant difference in behavior for NFS over UDP.  However, for the sake of technical completeness:  The older options (nosharetransport and sharetransport= ) cause different UDP client source ports to be used for different NFS-over-UDP mounts.

nconnect cannot force two or more mounts using the same NFS server/version to use completely separate connections from each other.  One might want such an ability in certain circumstances.  One way to achieve this would be to bind multiple IP addresses to the NFS server and for a client to specify different IP addresses for different mounts.