由于多个客户端可以挂载同一个文件系统,如何在多个客户端之间保持数据一致性是个非常麻烦的问题,NFSv2和NFSv3没有规定具体的方法,一般的做法是客户端不定期检查文件是否发生了冲突,比如读操作中在发起READ请求前可能要发起GETATTR请求,判断本地缓存是否有效。在大规模系统中以及当客户端和服务器分布比较遥远时就会影响系统性能,因为GETATTR操作需要一定的执行时间。
NFSv4引入了一种机制保持文件缓存一致性,这种机制称为delegation。这种机制的基本原理是客户端A打开文件时服务器给客户端A颁发一个凭证,只要客户端A持有这个凭证就可以认为没有与其他客户端发生冲突,读写操作中就不需要发起GETATTR请求了。当客户端B试图访问同一个文件时,这两个客户端就发生了冲突。服务器先暂时不响应客户端B的请求,而是向客户端A发送RECALL请求。客户端A接收到RECALL请求后将缓存中的数据刷新到服务器中,然后将凭证交还给服务器。这时服务器再响应客户端B的请求。以后两个客户端就按照NFSv2、NFSv3中的方法检查文件冲突。因此,这种机制适用于只读文件系统,或者客户端对数据修改不频繁的文件系统。
1.反向通道
如果一个客户端持有delegation,当文件访问发生冲突时,服务器需要向客户端发送RECALL请求,收回delegation,这是请求是在一个反向通道上进行的。也就是说:客户端和服务端之间有两个RPC通道,正常的NFS请求在正向通道中传输,与delegation相关的请求在反向通道中传输。在反向通道中,NFS服务