Understanding NFS Mount Options for SAS Viya on Kubernetes

[#1]

Shared file storage is a common requirement in SAS Viya deployments on Kubernetes. It is often used to provide shared access to data for Compute Server sessions, CAS, batch workloads, user home directories, and other shared application paths.

For many customers, Network File System (NFS) storage is a practical option because it is widely supported across cloud providers and enterprise storage platforms. However, the NFS mount options used by the Linux client can influence throughput, latency, concurrency, metadata consistency, and recovery behaviour.

Some high-level guidance on NFS Tuning is provided in the SAS documentation: SAS Help Center: NFS Protocol and Client Mount Recommendations

This article expands a little further and provides a practical starting point for understanding commonly used NFS mount options with SAS Viya on Kubernetes and shouldn’t be considered as a universal production recommendation.  Always validate mount options with the storage vendor and benchmark with I/O workload tests.

Overview of NFS Mount Options

Here is an overview of the NFS client mount options that are commonly used:

Start with the storage platform

Before choosing mount options, confirm the following with the storage vendor or cloud provider:

• Which NFS protocol versions are recommended and supported.
• Whether nconnect is supported.
• Recommended rsize and wsize values.
• Whether the storage service has throughput limits based on capacity or service tier.
• Whether there are special Kubernetes CSI driver requirements.

Protocol version:

The vers option specifies the NFS protocol version, for example:

vers=3
vers=4.1

The best choice depends on the storage platform and customer requirements.

The following matrix is a practical starting point. Always verify with the storage vendor.

NFSv3 is stateless at the core protocol level, but file locking is handled separately through the Network Lock Manager protocol. NFSv4.x integrates locking into the main NFS protocol, which can improve consistency semantics but also introduces stateful protocol behaviour that should be considered for performance-sensitive workloads.

NFS metadata consistency issues

For some NFS storage appliances and workload patterns, NFSv3 can provide lower protocol overhead and better performance than NFSv4.x and can avoid NFS metadata consistency issues. The protocol choice should be validated with the storage vendor and tested with representative SAS Viya workloads, especially where shared paths, locking, or multi-pod access are involved.

nconnect:

The nconnect option allows the Linux NFS client to establish multiple TCP connections for a single NFS mount. This can improve throughput and concurrency when the client, network, and storage service have sufficient capacity.

Example:

nconnect=4

or:

nconnect=8

 

Traditionally, an NFS client uses a single TCP connection to an NFS endpoint. For high-throughput SAS workloads, a single connection can become a bottleneck. Increasing the number of connections can improve parallelism and help the client use more of the available storage bandwidth.

The following matrix is a practical starting point. Always verify with the storage vendor.

The reduced benefit at 56 GB likely reflects the storage volume's provisioned throughput ceiling, not a limitation of nconnect.

Note: The benchmark observations are included as illustrative examples only. They are not universal performance guarantees.

The main takeaway is that nconnect can provide significant benefit when the storage service, network, and client can use the extra concurrency. However, increasing the value beyond the storage vendor’s recommended setting might not provide further gains.

rsize and wsize

The rsize option controls the maximum read request size used by the NFS client. The wsize option controls the maximum write request size.

Examples:

rsize=262144,wsize=262144

or:

rsize=1048576,wsize=1048576

The largest commonly used value is 1 MiB, or 1048576 bytes. However, bigger is not always better. The optimal value depends on the storage system, workload type, I/O pattern, network, Linux kernel, and concurrency.

The following matrix is a practical starting point. Always verify with the storage vendor.

For SAS Viya, it is better to establish a tested baseline than to assume a single rsize/wsize value is universally correct.

Note: The benchmark observations are included as illustrative examples only. They are not universal performance guarantees.

The main takeaway is that rsize/wsize should be tested with representative SAS workloads. Storage-vendor defaults are important, but SAS workload patterns can produce different results.

Attribute caching: actimeo

NFS clients use attribute caching to reduce the number of metadata requests sent to the NFS server. Metadata includes information such as file size, permissions, ownership, timestamps, and directory entries.

The actimeo option sets the same timeout value for multiple attribute cache settings.

Example:

actimeo=30

Setting:

actimeo=0

effectively disables attribute caching.

 

Why actimeo=0 is risky for performance

Disabling attribute caching can improve how quickly clients detect metadata changes, but it can significantly increase metadata traffic to the NFS server.

In SAS Viya environments, this can be especially expensive for workloads that create, read, sort, merge, and delete many files. It can also affect workloads running across multiple pods and nodes.

In the benchmark results reviewed for this article, actimeo=0 caused a major degradation for SAS Compute workloads on Azure NetApp Files. The results showed approximately 5x to 7x slower elapsed times across the tested data sizes.

Note: The benchmark observations are included as illustrative examples only. They are not universal performance guarantees.

The main takeaway is to avoid disabling attribute caching globally unless the workload absolutely requires it and the performance impact is acceptable.

hard

The hard option tells the NFS client to keep retrying requests when the NFS server does not respond.

Example:

hard

For persistent SAS workloads, hard is generally preferred over soft because it reduces the risk of applications receiving I/O errors for storage interruptions.

A soft mount can return errors to the application after retries are exhausted. For data-processing workloads, this can increase the risk of incomplete output or data integrity problems.

noac

The noac option disables attribute caching. It can also force synchronous write behaviour, which can cause a significant performance penalty. Use noac only when strict metadata visibility is required and the performance impact has been tested. For most SAS Viya deployments, noac should not be part of a default NFS mount baseline.

timeo

The timeo option controls how long the NFS client waits for a response before retrying a request. The value is specified in deciseconds.

Example:

timeo=600 (default Linux value)

This means 600 deciseconds, or 60 seconds.

Do not reduce this value without understanding the effect on recovery behaviour and workload reliability.

retrans

The retrans option controls how many times the NFS client retries a request before taking further recovery action.

Example:

retrans=2

For many NFS-over-TCP configurations, the default is commonly suitable. Some storage vendors include an explicit retrans recommendation in their mount guidance.

The key point is to treat timeo and retrans together. They influence how the client behaves during server, network, or path interruptions.

Suggested starting points

The following examples are starting points only. They must be validated with the storage vendor and tested in the customer environment.

 

Azure Premium Files NFS

A practical starting point for testing might include:

vers=4.1,nconnect=4,rsize=262144,wsize=262144,hard,timeo=600,retrans=2

Use representative SAS workloads to decide whether 256K or 1M transfer sizes are better.

Azure NetApp Files or NetApp ONTAP

A practical starting point for testing might include:

nconnect=4,rsize=262144,wsize=262144,hard,timeo=600

Select vers=3 or vers=4.1 based on storage support, locking and consistency requirements, security requirements, and benchmark results.

Amazon EFS

Do not use nconnect with Amazon EFS.

Follow AWS EFS mount guidance. A common EFS-style baseline includes options such as:

noresvport,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Validate with the EFS CSI driver and AWS documentation.

Summary

NFS mount options can make a significant difference to SAS Viya performance and reliability on Kubernetes.

The most important practical points are:

1. Start with the official SAS documentation and the storage-vendor guidance.
2. Confirm whether nconnect is supported before using it.
3. Use a consistent Kubernetes storage configuration so all pods mount the same NFS endpoint with the intended options.
4. Benchmark rsize and wsize with representative SAS workloads.
5. Avoid actimeo=0 as global defaults because they can significantly degrade performance.
6. Use hard mounts for persistent SAS workloads unless there is a specific reason not to.
7. Validate the effective mount options after deployment.
8. Treat benchmark results as workload-specific, not universal.

A good NFS configuration for SAS Viya is not just a list of mount options. It is the combination of storage platform, Linux client, Kubernetes configuration, network capacity, workload pattern, and operational requirements.