VAST has its own NFS client, plainly called VAST NFS which implements a bunch of mount options that improve performance. VAST makes every effort to upstream these options, but not all of them are accepted into Linux.
nconnect and remoteports
nconnect
This option allows a single NFS mount to utilize more than one connection to break through the 2 GB/s limit of a single mount.
Upstream Linux now supports this, but the VAST NFS driver supports high maximum values (e.g., 64 connections per mount).
remoteports / multipath
VAST supports allowing a single mount to access via multiple IP addresses. In order for this to work correctly, all IP addresses (NFS servers) must have a consistent view of the data it is serving. This is possible with some clustered NFS implementations, but not all clustered NFSes achieve the performance uplift that VAST does by specifying remoteports.
Interactions
When both nconnect
and remoteports
are specified, nconnect
connections are distributed across remoteports
. This results in the following behavior:
- If you have
nconnect=8
and specify eight IPs forremoteports
, you get one connection per remoteport. - If you have
nconnect=7
and eightremoteports
, I don’t know what happens. I think you only use seven of the eight remote ports. - If you have
nconnect=16
and eight remoteports, each remoteport gets two connections. - If you have
nconnect=9
and eight remoteports, I don’t know what happens.
These semantics mean that, in order to actually use multipathing, your nconnect must be higher than 1. Otherwise, you only use one connection and one remote port, which is no different than not specifying nconnect or remoteports.
It’s generally a good idea to have nconnect
be evenly divisible by the number of remoteports
. This way, connections are evenly balanced across remote ports.
Spreading I/O
The vastnfs driver also supports two non-upstream options, spread_reads
and spread_writes
, which allow single-file accesses from a single client to be sprayed across multiple remoteports. This occurs at the RPC level, so the size of sharding is dictated by the mount options (rsize
/wsize
) for large writes, write size (if direct I/O is at play), or read size.