如何保证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 将会有更多的期待。

本文转载自公众号阿里技术（ID：ali_tech）。

原文链接：

https://mp.weixin.qq.com/s/lcrI3hzIplrQHs5aB_9Prg