NFS version 3 has been a gold standard for NFS applications for decades – starting all the way back in 1995, when it was first officially released. Its blend of performance and resiliency has made it difficult to consider a move to newer NFS versions for good reason.
However, NFSv3 is not without its limitations. Statelessness of the protocol, while great for performance and for minimizing disruptions on storage failover, is not so great for data consistency and lock management. An NFS server doesn’t really keep track of lock states, so if there is a failure, the NFS server may or may not release the locks, and the NFS client may not know whether a file is locked or not.
Security for NFSv3 is also a bit lacking. The protocol requires multiple open firewall ports to function properly and numeric IDs are sent in plaintext over the wire. Furthermore, NFS does not have robust ACL support, and does not include native file and folder auditing. As a result of these limitations, NFSv4 was created in 2003 via RFC-3530 (obsoleted in 2015 by RFC-7530).
What does NFSv4 bring to the equation?
NFSv4 delivers a number of improvements over NFSv3, including:
Integrated locking
Rather than splitting lock mechanisms into their own services (such as NLM and NSM) from the NFS protocol itself, which require their own network ports and can create stale lock issues in failover scenarios, NFSv4 integrates locking directly into the protocol stack. That way, the client and server always agree on the lock states. If a client or server has an extended failure, then locks will eventually expire on their own, which prevents stale lock issues.
Firewall friendly
NFSv4 integrates many of the services that NFSv3 separated out, such as mount, portmapping, locking, etc, into the protocol. As a result, only port 2049 (the NFS port) is required for use of NFSv4, which makes the protocol firewall friendly.
Granular access controls
NFSv3 supports basic mode bit permissions (such as RWX) with a limitation of owner, group, and everyone else as the only subjects to which permissions can be applied. These limitations make it difficult to create granular access controls for additional users and groups. NFSv4 attempts to improve upon that by implementing support for NFSv4 access control lists (ACLs). These ACLs provide a way to manage access not just for basic RWX across only a small subset of subjects, but also for a larger number of file operations (such as deletes, ownership changes, permission changes, etc) across up to 1024 owner and group objects. An added benefit in ONTAP environments is that NFS access controls can more closely match NTFS permissions, which makes multiprotocol NAS access across NFS and SMB to the same datasets more seamlessly integrated.
Name string/domain enforcement
NFSv3 users and groups send numeric IDs to the NFS server by default, which means that the NFS server then must translate that numeric ID into a human-readable name. NFSv4, on the other hand, will send name strings (ie, user@DOMAIN.COM) to the server, which not only helps prevent spoofing of numeric IDs, but also requires the client and server to negotiate the name strings with identical local representation of users and groups (either via local files or LDAP). If the name string translation fails, then the NFS server will squash the user or group to the anonymous user defined by the NFS client’s configuration. This helps prevent unintentional or unauthorized access to files and folders.
File and folder auditing
In addition to security Access Control Entries (ACEs), NFSv4 also supports the ability to add audit ACEs to files and folders to track and log specific file operations. For instance, if you want to see who is attempting to read or delete a file, audit ACEs can track that. Native NFSv3 supported no such capability.
Kerberos mandate
Kerberos authentication provides an optional extra layer of security for NFS access by requiring users to enter a username and password to collect a Kerberos ticket to initially access NFS shares. Kerberos can also be leveraged to further encrypt data traffic end-to-end (with a performance impact due to the encryption/decryption CPU work) for added security, and since all NFS functionality is integrated into the same port, all NFS traffic would be encrypted – including mounts and locks. While the NFSv4 RFC mandates Kerberos support by the NFS server, use of Kerberos is optional.
Additional features and functionality
While NFSv4 added a multitude of new functionality within the protocol stack, perhaps the biggest improvement the new version brought was the addition of new features and functionality for NFS in general.
These include:
- Parallel NFS (NFS v4.1)
- NFS session trunking (NFSv4.1)
- File delegations (NFSv4.1)
- Referrals (NFSv4.1)
- Stateless migration (NFSv4.1)
- Security labels (NFSv4.2)
- Extended attributes (NFSv4.2)
For a deeper look:
NFSv3 and NFSv4: What's the difference? - NetApp Community
Sounds great… why don’t more people use it?
While NFSv4.x has been around for over 20 years, there still hasn’t been widespread adoption of it for a few reasons.
- Complexity of identity management: Many environments don’t have a name service infrastructure in place to properly take advantage of the name string and Kerberos security requirements in NFSv4.x.
- Need for newer NFS clients: This concern is less pressing in today’s modern NFS environments, as the further we get from the initial release date of NFSv4. Almost all currently used OS’s include NFS clients with full NFsv4 support, but there are still legacy systems that may not have the necessary NFSv4.x packages. In fact, some applications still require use of older NFS versions.
- “If it ain’t broke, don’t fix it” mentality: Enterprise IT organizations are notoriously conservative in adoption of newer technologies – even ones that have been around for over 20 years. And if the current NFS version is working fine, why change?
- Performance concerns: Performance of a stateful protocol like NFSv4.x has lagged behind stateless NFSv3 for much of the past 20 years. In the past, the performance impact often outweighed the NFSv4.x benefits.
What is NetApp AFX?
NetApp AFX is the latest innovation from NetApp that introduces the use of disaggregated storage with NAS and object for high performance workloads, such as AI/ML, EDA, HPC and anything that requires independent scaling of capacity and compute, massive throughput, and a single capacity pool.
AFX does all of this while still running the same ONTAP images as unified ONTAP. That means you get all of the same ONTAP functionality and interoperability (such as SnapMirror and FlexCache) you’re accustomed to.
Since disaggregated ONTAP is a new way to consume ONTAP, it opens the door to additional performance gains, such as the changes made in ONTAP 9.18.1 to improve overall performance for NFSv4.x.
NFSv4.x improvements in ONTAP 9.18.1 using AFX
Some architectural changes to ONTAP have provided a much needed performance boost to NFS in general, and have made some serious inroads to improving NFSv4.x performance in general.
Below is a high-level summary of some of those changes.
Sequential read enhancement - NFSv4.1 30% better than NFSv3
ONTAP 9.18.1 introduces support for multipath IO with NFSv4.1. Rather than processing reads from the WAFL file system, MPIO shifts read operations into a network domain to be served in a multipath-safe manner. This approach reduces context switches, providing greater overall parallelism in sequential read traffic, as well as reducing the overhead from buffer management by bypassing WAFL.
Random read enhancement for FlexGroup volumes – NFSv4.1 within 7% of NFSv3
FlexGroup volumes are volumes that take many underlying constituent volumes and present them as a single unified namespace. In AFX, FlexGroup volumes have Advanced Capacity Balancing enabled by default, which will write files larger than 10GB across multiple constituent volumes as multipart files. Because of the remote location of these file parts, random reads traditionally have had a modest perf disadvantage with NFSv4.x (around 18% less than NFSv3). ONTAP 9.18.1 introduces support for cached IO for multipart reads with NFSv4.x to help address this.
Note: This change does not apply to FlexVol volumes.
Sequential writes - +10% improvement from previous releases
An improvement of how we replicate NVLOG data used for HA failover functionality increased overall sequential write performance for NetApp AFX systems.
Metadata operations – Within 15% performance of NFSv3 for EDA benchmarks
NFSv4.1 traditionally serializes all OPEN and CLOSE operations, with a cluster node processing them one at a time before they can be sent from the network to WAFL. ONTAP 9.18.1 introduces Concurrent Open Close (COC), which eliminates network serialization by changing how race conditions are resolved, which removes OPEN/CLOSE bottlenecks seen in prior releases.
All of these changes – along with the architecture changes brought about in AFX – have made it possible to improve the overall NFSv4.1 performance in ONTAP 9.18.1.
Sequential IO results
One of the areas where some modest performance improvements were seen was with sequential IO (ie, IO that is predictable and issued consecutively). In standard performance tests using fio, AFX running ONTAP 9.18.1 improved sequential read performance by nearly 30% and sequential write performance by 10%.
Metadata-heavy workload results
Even more impressive are the improvements with one of NFSv4.x’s top performance pain points – metadata. These are random IOs, usually in the 4K range, used to manage file owners and attributes, creating and listing files, and so on. Because of the statefulness of NFSv4.x, these types of operations tend to cost more in CPU and latency, which in turn reduces overall possible performance.
With the changes in AFX ONTAP 9.18.1, NFSv4.x performance for these types of workloads has improved substantially and has closed the gap on NFSv3 performance (within 15%).
Our performance engineering teams compared performance of standard AI image, EDA, and software build benchmarks and found massive gains from the previous ONTAP release.
So now what?
With the latest NFSv4.x performance improvements (along with the other benefits of NFSv4.x), it’s likely worth revisiting use of NFSv4.x in your high-performance NAS workloads. Either test it out with your applications or schedule a meeting with our Customer Proof of Concept (CPOC) labs through your NetApp sales representative. If you’d like to learn more about CPOC, check out this Tech ONTAP Podcast episode:
If you’d like to learn more about NFSv4.x, these links can also help: