如何保证NFS文件锁的一致性？

简介：在存储系统中， NFS（Network File System，即网络文件系统）是一个重要的概念，已成为兼容POSIX语义的分布式文件系统的基础。它允许在多个主机之间共享公共文件系统，并提供数据共享的优势，从而最小化所需的存储空间。本文将通过分析NFS文件锁状态视图一致性的原理，帮助大家理解NFS的一致性设计思路。

文件锁

文件锁是文件系统的最基本特性之一，应用程序借助文件锁可以控制其他应用对文件的并发访问。NFS作为类UNIX系统的标准网络文件系统，在发展过程中逐步地原生地支持了文件锁(从NFSv4开始)。NFS从上个世界80年代诞生至今，共发布了3个版本：NFSv2、NFSv3、NFSv4。

NFSv4最大的变化是有“状态”了。某些操作需要服务端维持相关状态，如文件锁，例如客户端申请了文件锁，服务端就需要维护该文件锁的状态，否则和其他客户端冲突的访问就无法检测。如果是NFSv3就需要NLM协助才能实现文件锁功能，但是有的时候两者配合不够协调就会容易出错。而NFSv4设计成了一种有状态的协议，自身就可以实现文件锁功能，也就不需要NLM协议了。

应用接口

应用程序可以通过 fcntl() 或 flock() 系统调用管理NFS文件锁，下面是NAS使用NFSv4挂载时获取文件锁的调用过程：

从上图调用栈容易看出，NFS文件锁实现逻辑基本复用了VFS层设计和数据结构，在通过RPC从Server成功获取文件锁后，调用 locks_lock_inode_wait() 函数将获得的文件锁交给VFS层管理，关于VFS层文件锁设计的相关资料比较多，在此就不再赘述了。

EOS原理

文件锁是典型的非幂等操作，文件锁操作的重试和Failover会导致文件锁状态视图在客户端和服务端间的不一致。NFSv4借助SeqId机制设计了最多执行一次的机制，具体方法如下：

针对每个open/lock状态，Client和Server同时独立维护seqid，Client在发起会引起状态变化的操作时(open/close/lock/unlock/release_lockowner)会将seqid加1，并作为参数发送给Server，假定Client发送的seqid为R，Server维护的seqid为L，则：

• 若R == L +1，表示合法请求，正常处理之。
• 若R == L，表示重试请求，Server将缓存的reply返回即可。
• 其他情况均为非法请求，决绝访问。

根据上述规则，Server可判断操作是否为正常、重试或非法请求。

该方法能够保证每个文件锁操作在服务端最多执行一次，解决了RPC重试带来的重复执行的问题，但是仅靠这一点是不够的。比如LOCK操作发送后调用线程被信号中断，此后服务端又成功接受并执行了该LOCK操作，这样服务端就记录了客户端持有了锁，但客户端中却因为中断而没有维护这把锁，于是就造成了客户端和服务端间的锁状态视图不一致。因此，客户端还需要配合处理异常场景，最终才能够保证文件锁视图一致性。

异常处理

由上一节的分析可知，客户端需要配合处理异常场景才能够保证文件视图一致性，那么客户端设计者主要做了哪些配合的设计呢？目前客户端主要从SunRPC和NFS协议实现两个维度相互配合解决该问题，下面分别介绍这两个维度的设计如何保证文件锁状态视图一致性。

SunRPC设计

SunRPC是Sun公司专门为远程过程调用设计的网络通讯协议，这里从保障文件锁视图一致性的维度来了解一下SunRPC实现层面的设计理念：

（1）客户端使用int32_t类型的xid标识上层使用者发起的每个远程过程调用过程，每个远程过程调用的多次RPC重试使用相同的xid标识，这样就保障了多次RPC重试中任何一个返回都可以告知上层远程过程调用已经成功，保证了服务端执行远程过程调用执行耗时较长时也能拿到结果，这一点和传统的netty/mina/brpc等都需要每个RPC都要有独立的xid/packetid不同。

（2）服务端设计了DRC(duplicate request cache)缓存最近执行的RPC结果，接收到RPC时会首先通过xid检索DRC缓存，若命中则表明RPC为重试操作，直接返回缓存的结果即可，这在一定程度上规避了RPC重试带来的重复执行的问题。为了避免xid复用导致DRC缓存返回非预期的结果，开发者通过下述设计进一步有效地减少复用引起错误的概率：

• 客户端建立新链接时初始xid采用随机值。
• 服务端DRC会额外记录请求的校验信息，缓存命中时会同时校验这些信息。

（3）客户端允许在获得服务端响应前无限重试，保证调用者能够获得服务端确定性的执行结果，当然这样的策略会导致无响应时调用者会一直hang。

（4）NFS允许用户在挂载时通过soft/hard参数指定SunRPC的重试策略，其中soft模式禁止超时后重试，hard模式则持续重试。当用户使用soft模式挂载时NFS实现不保证客户端和服务端状态视图的一致性，在遇到远程过程调用返回超时要求应用程序配合状态的清理和恢复，比如关闭访问出错的文件等，然而实践中很少有应用程序会配合，所以一般情况下NAS用户都使用hard模式挂载。

总之，SunRPC要解决的核心问题之一是，远程过程调用执行时间是不可控的，协议设计者为此定制化设计，尽量避免非幂等操作RPC重试带来的副作用。

信号中断

应用程序等待远程过程调用结果时允许被信号中断。当发生信号中断时，由于没有得到远程过程调用的执行结果，所以客户端和服务端的状态很可能就不一致了，比如加锁操作在服务端已经成功执行，但客户端并不知道这个情况。这就要求客户端做额外的工作将状态和服务端恢复一致。下面简要分析获取文件锁被信号中断后的处理，来说明NFS协议实现层面的一致性设计。

通过获取NFSv4文件锁的过程可知，NFSv4获取文件锁最终会调用 _nfs4_do_setlk() 函数发起RPC操作，最终调用 nfs4_wait_for_completion_rpc_task() 等待，下面是相关代码：

static int _nfs4_do_setlk(struct nfs4_state *state, int cmd, struct file_lock *fl, int recovery_type) 
{      
  ......     
  task = rpc_run_task(&task_setup_data);     
  if (IS_ERR(task))         
      return PTR_ERR(task);     
  ret = nfs4_wait_for_completion_rpc_task(task);     
  if (ret == 0) {         
      ret = data->rpc_status;         
      if (ret)             
              nfs4_handle_setlk_error(data->server, data->lsp,                     
                  data->arg.new_lock_owner, ret);     
      } else         
          data->cancelled = 1;       
  ......     
}

通过分析 nfs4_wait_for_completion_rpc_task() 实现可知，当ret < 0时，表明获取锁过程被信号中断，并使用 struct nfs4_lockdata 的 cancelled 成员记录。继续查看rpc_task完成后释放时的回调函数 nfs4_lock_release()：

从上面红色框中的代码可知，nfs4_lock_release() 检测到存在信号中断时会调用 nfs4_do_unlck()函数尝试将可能成功获得文件锁释放掉，注意此时没有调用 nfs_free_seqid() 函数将持有的nfs_seqid释放掉，这是为了：

• 保证订正状态过程中不会有用户新发起的并发加锁或者释放锁操作，简化实现。
• 保证hard模式下UNLOCK操作只会在LOCK操作返回后才会发送，保障已经获得锁能够被释放掉。

客户端通过上面的方法能够有效地保证信号中断后客户端和服务端锁状态的最终一致性,但也是在损失一部分可用性为代价的。

总结

文件锁是文件系统原生支持的基础特性，NAS作为共享的文件系统要面临客户端和服务端锁状态视图一致性的问题，NFSv4.0在一定程度上解决了这个问题，当然，技术前进的脚步不会停止，NFS的更新迭代也就不会停止，未来的NFS将会有更多的期待。

最后

我们相信技术的力量，更相信拥有技术力量的人。我们期待存储的未来，更期待与你一起创造未来。

原文链接：https://developer.aliyun.com/article/769594?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。