NFS is a network file system. Since its launch in 1985, three versions have been released: NFSv2, NFSv3, and NFSv4. NFSv4 includes two minor versions, NFSv4.0 and NFSv4.1. After more than 20 years of development, NFS has undergone great changes. The biggest change is that the promoter has changed from Sun to NetApp. NFSv2 and NFSv3 were basically drafted by Sun. NetApp participated from NFSv4.0 and dominated NFSv4.1 Standard development process, and Sun has been acquired by Oracle.
| serial number | Version | RFC | time | number of pages |
| 1 | NFSv2 | rfc1094 | March 1989 | 27 pages |
| 2 | NFSv3 | rfc1813 | June 1995 | 126 pages |
| 3 | NFSv4.0 | rfc3530 | April 2003 | 275 pages |
| 4 | NFSv4.1 | rfc5661 | January 2010 | 617 pages |
1. NFSv2
NFSv2 was the first version published as an RFC and implemented basic functionality.
2. NFSv3
NFSv3 was released in 1995, when NFSv2 had been released for 6 years, NFSv3 corrected some bugs of NFSv2. There are some differences between the two as follows, but there is no essential difference in feeling.
(1) NFSv2 imposes a limit on the maximum length of data transmitted in each read and write operation, the upper limit is 8192 bytes, and NFSv3 cancels this limit.
(2) NFSv3 imposes a limit on the length of the file name, the upper limit is 255 bytes, and NFSv3 cancels this limit.
(3) NFSv2 imposes a limit on the length of the file, the upper limit is 0x7FFFFFFF, and NFSv3 cancels this limit.
(4) The length of the file handle in NFSv2 is fixed at 32 bytes, and the length of the file handle in NFSv3 is variable, and the upper limit is 64 bytes.
(5) NFSv2 only supports synchronous writing. If the client writes data to the server, the server must write the data to the disk before sending a reply message. NFSv3 supports asynchronous write operations, and the server only needs to write the data into the cache to send the response information. NFSv3 adds a COMMIT request, which can flush the data in the server cache to disk.
(6) NFSv3增加了ACCESS请求，ACCESS用来检查用户的访问权限。因为服务器端可能进行uid映射，因此客户端的uid和gid不能正确反映用户的访问权限。NFSv2的处理方法是不管访问权限，直接返送请求，如果没有访问权限就出错。NFSv3中增加了ACCESS请求，客户端可以检查是否有访问权限。
(7) 一些请求调整了参数和返回信息，毕竟NFSv3和NFSv2发布的间隔有6年，经过长期运行可能觉得NFSv2某些请求参数和返回信息需要改进。
3. NFSv4.0
相比NFSv3，NFSv4发生了比较大的变化，最大的变化是NFSv4有状态了。NFSv2和NFSv3都是无状态协议，服务区端不需要维护客户端的状态信息。无状态协议的一个优点在于灾难恢复，当服务器出现问题后，客户端只需要重复发送失败请求就可以了，直到收到服务器的响应信息。但是某些操作必须需要状态，如文件锁。如果客户端申请了文件锁，但是服务器重启了，由于NFSv3无状态，客户端再执行锁操作可能就会出错了。NFSv3需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调。NFSv4设计成了一种有状态的协议，自身实现了文件锁功能，就不需要NLM协议了。NFSv4和NFSv3的差别如下：
(1) NFSv4设计成了一种有状态的协议，自身实现了文件锁功能和获取文件系统根节点功能，不需要NLM和MOUNT协议协助了。
(2) NFSv4增加了安全性，支持RPCSEC-GSS身份认证。
(3) NFSv4只提供了两个请求NULL和COMPOUND，所有的操作都整合进了COMPOUND中，客户端可以根据实际请求将多个操作封装到一个COMPOUND请求中，增加了灵活性。
(4) NFSv4文件系统的命令空间发生了变化，服务器端必须设置一个根文件系统(fsid=0)，其他文件系统挂载在根文件系统上导出。
(5) NFSv4支持delegation。由于多个客户端可以挂载同一个文件系统，为了保持文件同步，NFSv3中客户端需要经常向服务器发起请求，请求文件属性信息，判断其他客户端是否修改了文件。如果文件系统是只读的，或者客户端对文件的修改不频繁，频繁向服务器请求文件属性信息会降低系统性能。NFSv4可以依靠delegation实现文件同步。当客户端A打开一个文件时，服务器会分配给客户端A一个delegation。只要客户端A具有delegation，就可以认为与服务器保持了一致。如果另外一个客户端B访问同一个文件，则服务器会暂缓客户端B的访问请求，向客户端A发送RECALL请求。当客户端A接收到RECALL请求时将本地缓存刷新到服务器中，然后将delegation返回服务器，这时服务器开始处理客户端B的请求。
(6) NFSv4修改了文件属性的表示方法。由于NFS是Sun开发的一套文件系统，设计之出NFS文件属性参考了UNIX中的文件属性，可能Windows中不具备某些属性，因此NFS对操作系统的兼容性不太好。NFSv4将文件属性划分成了三类：
Mandatory Attributes: 这是文件的基本属性，所有的操作系统必须支持这些属性。
Recommended Attributes: 这是NFS建议的属性，如果可能操作系统尽量实现这些属性。
Named Attributes: 这是操作系统可以自己实现的一些文件属性。
4. NFSv4.1
与NFSv4.0相比，NFSv4.1最大的变化是支持并行存储了。在以前的协议中，客户端直接与服务器连接，客户端直接将数据传输到服务器中。当客户端数量较少时这种方式没有问题，但是如果大量的客户端要访问数据时，NFS服务器很快就会成为一个瓶颈，抑制了系统的性能。NFSv4.1支持并行存储，服务器由一台元数据服务器(MDS)和多台数据服务器(DS)构成，元数据服务器只管理文件在磁盘中的布局，数据传输在客户端和数据服务器之间直接进行。由于系统中包含多台数据服务器，因此数据可以以并行方式访问，系统吞吐量迅速提升。