During EMC World this year, we received a customer request for more information about NFS support in OneFS 7.2. NFS support was significantly improved in OneFS 7.2, moving the NFS server out of the OS kernel and into user space, adding support for access zones, and offering a better overall NFS experience for customers. If NFS is critical to your workflow, you should definitely consider upgrading to OneFS 7.2.


First, a little history


Prior to OneFS 7.2, NFS calls were primarily handled in the OS kernel. A client would initiate an NFS connection, processing would commence in the kernel, and the result would be passed back to the client. The problem with this approach was that heavy duty NFS-using customers, who were creating tens of thousands of NFS exports, were overloading the kernel with NFS processes. This could cause the NFS server to be slow or unresponsive, and could slow down other processes in the kernel, as well. In the worst case, a node would crash.


Also, prior to OneFS 7.2, administrators could drive themselves crazy tweaking NFS settings to try to improve performance, but often would end up making things worse.


Earlier versions of OneFS supported NFSv2, NFSv3, and NFSv4. But there was no support for access zones, as there was with SMB. Consequently, it was not as straightforward to secure NFS exports from users who should not have access to them.


NFS support in OneFS 7.2


With OneFS 7.2, customers who upgrade will find a host of improvements:


  • NFS exports are now presented through the OneFS access zone system to better support multi-tenancy. NFS exports must be associated with an access zone, and are available only to users associated with this access zone. In addition, administrators can use ACLs to further enhance protection of files available through an NFS export.


  • Many of the changes were under the hood to improve performance and eliminate bottlenecks. First and foremost, the NFS server was moved out of the kernel and into user space. A lot of work was done on the threading model and caching to improve performance. A scheduler was added to manage operations and their interactions, improving efficiency and reducing redundancy. A fairness algorithm was introduced to make sure that no single NFS client could hog resources. A throttling mechanism was added to make sure that the NFS server could scale to large workloads, and not run out of memory.


  • In addition, a LIN tree was added to enable mounts to be refreshed in seconds (versus hours in a large-scale deployment). This capability is said to speed up NFSv4 deployments a lot (although NFSv3 deployments only a little).


  • Because of improved resource management, there is no need for administrators to tweak advanced export settings to improve performance. In fact, in the web administration interface, there is a warning message on the NFS Exports page that says:


  • NFS was also made part of a user-mode server infrastructure (Likewise) that also supports SMB. This unified infrastructure has proven to be invaluable in several respects: performance, maintenance, serviceability, and protocol unification (providing a common run-time environment), and will likely be used in the future to include support for other frameworks such as Hadoop and FDP.


  • Finally, NFS aliases are supported, which enable users to more quickly specify an NFS export to connect to. For example, you could create an alias such as /finance2015 for a long directory path such as /ifs/data/departments/finance/records/archive/2015.


More information about OneFS 7.2 can be found at our OneFS 7.2 Documentation – Info Hub.