BatchFS: Scaling the File System Control Plane with Client-Funded Metadata Servers——论文泛读

PDSW 2014 Paper 分布式元数据论文阅读笔记整理

问题

并行文件系统通常使用分层体系结构，将元数据管理与I/O操作解耦，促进对文件内容的快速并发访问。然而，由于命名空间同步，元数据密集型工作负载仍然可能在文件系统控制平面上成为瓶颈，由于目录上的锁争用、事务序列化、RPC开销、负载失衡等降低应用程序性能。

本文方法

文件系统控制平面受到元数据服务器能够提供的最大元数据性能的限制。为了更好地适应元数据密集的大规模并行HPC工作负载，本文提出了一种客户端驱动的文件系统元数据架构，允许应用程序在本地处理自己的元数据操作，而无需服务器干预。从而避免RPC开销，并保护应用程序免受服务器端不必要的资源争用，允许系统扩展到固定大小的控制平面之外。

本文提出了客户端驱动的文件系统元数据架构BatchFS，针对非交互或批处理工作负载进行了优化。

• 许多文件系统都是为最坏的情况而设计的，在这种情况下，应用程序依赖于强一致的文件系统来相互同步。对于批处理应用程序来说，这往往不需要，因为它们可以在几乎没有外部协调的情况下协同执行任务。BatchFS利用了这一机会，使用宽松的一致性模型来管理批处理应用程序元数据。

• 应用程序通过链接到用户级库文件系统来获得本地处理命名空间操作的能力，该文件系统可以直接访问文件系统元数据，该元数据表示为存储在共享底层持久层中的一组日志结构的数据。每个作业都对文件系统快照进行操作，并自行管理其命名空间。通过重用服务器端逻辑，应用程序能够将元数据修改直接编码到磁盘上的元数据表示形式（以及预写日志）中。最终需要同步时，客户端将其修改后的文件系统快照提交给全局主快照，以便合并更新。

• 为了确保去中心化文件系统元数据层中的全局命名空间语义的安全，使用乐观服务器端命名空间验证，为批处理应用程序批量插入的所有合法元数据操作建立总顺序。为了以可扩展的方式工作，引入了辅助元数据服务器，是在具有根权限的客户端资源上运行的临时守护进程。这些服务器由受信任的虚拟机保护，负责验证不受信任的客户端文件系统修改，并将其提交到全局主映像中。

实验表明，客户端资助的元数据体系结构比传统的同步文件系统好几个数量级。

总结

针对用于大规模HPC的并行文件系统，现有方法受到目录上的锁争用、事务序列化、RPC开销、负载失衡等降低应用程序性能。本文提出客户端驱动的文件系统元数据架构BatchFS，针对非交互或批处理工作负载进行了优化。包括3个优化点：（1）放松的一致性模型，对于批处理工作负载可以在几乎没有外部协调的情况下协同执行任务，不需要实现强一致性。（2）惰性命名空间同步，每个作业都对文件系统快照进行操作，并自行管理其命名空间，最终同步到主快照中，减少了同步数量。（3）乐观元数据验证，确保全局命名空间语义的安全，为元数据操作建立总顺序。