如何保证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()：