客户端缓存一致性

我一直回避着如何管理客户端元数据缓存一致性的问题，认为这会使客户端/MDS 协议和 MDS 变得复杂。然而，Zach 在 CRFS 方面取得的进展让我再次思考这个问题，并且我意识到，为了使 MDS 集群和客户端文件数据上的能力工作，大部分复杂的部分都已经处理过了

• 大部分 MDS 代码已经以允许阻塞的通用锁框架编写
• 用于处理死掉或无响应客户端的文件 I/O 能力的客户端会话超时基础设施已经存在

客户端已经维护并检查基于一个蹩脚的固定超时缓存方案的每个对象的 TTL 值。真正需要的是 MDS 响应消息中的一些额外标志来授予租约，MDS 中的一个额外对象来跟踪客户端元数据对象的副本，以及一个简单的租约撤销/释放消息处理程序。令我惊喜的是，在编码几个小时后，事情基本上就完成了。

协议和数据结构最初将仅支持租约的相对简单的组合。例如，不同的 inode 字段由不同的锁保护（例如，uid/gid/mode 与文件大小），并且可以独立地授予或撤销字段上的租约，但它们将共享一个租约间隔。不过，这实际上可以捕获大多数工作负载的大部分性能，并使 MDS 上的事情（相对）简单。

最终，我想将文件能力应用于目录，以便客户端可以异步地从 MDS 创建文件并写入它们（通过基本上预分配未使用的 inode 编号）。我还没有完全考虑清楚，但我认为这将提供大部分缺失的基础设施，使类似的事情能够工作……