Home > Storage > PowerScale (Isilon) > Product Documentation > Protocols > PowerScale OneFS NFS Design Considerations and Best Practices > NFS protocol introduction
The Network File System (NFS) protocol allows users to mount remote file systems transparently and access to shared files across networks. It uses a client/server model based on Remote Procedure Call Protocol (RFC5531), so NFS is portable across different machines, operating systems, network architecture, and transport protocols. NFS eliminates the need to keep copies of files on several machines by letting the clients all share a single copy of a file on the server.
There are three major NFS versions. Each of them is defined in an RFC specification as shown in the following table. This chapter provides a brief summary about NFSv3 and NFSv4.x as they are implemented in most enterprise environments. For more details, see the links in the table.
Version | RFC | Status |
NFSv2 | RFC1094 (published in 1989) | Obsolete |
NFSv3 | RFC1813 (published in 1995) | Most popular |
NFSv4.0 | RFC3010 (published in 2000, obsolete) | Slowly replacing NFSv3 |
RFC3530 (published in 2003, obsolete) | ||
RFC7530 (published in 2015) | ||
NFSv4.1 | RFC5661 (published in 2010) | Adopted gradually |
NFSv4.2 | RFC7862 (published in 2016) |
The NFSv3 is a stateless protocol. Statelessness means that the server does not need to maintain state about any of its clients in order to function correctly. The NFSv3 has following key enhancements compared with NFSv2:
To function correctly, NFSv3 also relies on several auxiliary protocols.
Mount protocol
The mount protocol is separate from, but related to, the NFS protocol. It provides operating system-specific services to get NFS off the ground - looking up export pathnames, validating user identity, and checking access permissions. Clients use the mount protocol to get the first file handle, which allows them entry into a remote file system.
Network Lock Manager (NLM) protocol and Network Status Monitor (NSM) protocol
Because NFS is a stateless service, auxiliary protocols are needed to offer inherently stateful services such as file locking and access control synchronization. So the RPC-based NLM protocol and NSM protocol work together to provide file locking and access control capability.
Binding protocol (RFC1833)
As NFS protocol and its auxiliary protocols mentioned above are all based on RPC, it is necessary to map RPC program number/version number pairs to the network port number (TCP/UDP port number) for that version of that program. Binding protocol provides such a lookup service to find a network port number for a specific RPC program number/version. There are three versions of a lookup service: RPCBIND (Versions 3 and 4) which uses a transport-independent format for the transport address, and Port Mapper (Version 2) which is an older protocol only specific for TCP and UDP transport.
The biggest change in NFSv4.x is that it is designed as a stateful protocol. Unlike earlier NFS versions which needs auxiliary protocols to provide additional functions, the NFSv4.x integrates the file locking (NLM/NSM) and the mount protocol. Besides, the NFSv4.x also provides some of the key features as follows:
The NFSv4.x retains the essential characteristics of the previous version, such as independent of operating systems, simplicity, and good performance. It also has more advantages compared with older versions.
COMPOUND procedure
The compound procedure will combine multiple individual operations into a single request to reduce the number of RPC packets transmitted over the network. The client can avoid the cumulative latency of multiple RPCs. So the NFSv4.x will perform better in a potentially high latency network like the Internet.
Firewall friendly
To access an NFSv3 server, the client needs to involve NFS protocol and its auxiliary protocols (port mapper, mount, NLM/NSM), each of them needs TCP/UDP ports which would not be the well-known ports listening on the network. This will cause problems for using NFS through firewall. In the NFSv4.x, there are no auxiliary protocols and it is designed as a single protocol using a single TCP port, usually listening on port 2049. So it traverses firewalls and network address translation (NAT) devices easily, and makes the network management and configuration easily. More details and considerations are discussed in Network security considerations.
Stronger security
The NFSv4.x ACL file attribute is added to enable more expressive access control. The NFSv4.x ACL model is quite rich. With the use of NFSv4.x ACL, the server does all access control based on the server’s interpretation of the ACL although the client can manipulate the ACL attributes. More details and considerations are discussed in NFSv4.x ACL.