【Ceph RADOS】CephFS / MDS：可恢复元数据服务、subtree 分区与 POSIX 代价
内容提要
CephFS将POSIX文件系统构建于RADOS之上，MDS作为可恢复状态机，通过journal持久化元数据。其核心挑战包括：MDS故障恢复、capability机制维持客户端缓存一致性、多active MDS的subtree迁移可能引发thrashing，以及fsync/stat操作的高网络往返成本。相比RBD，CephFS在元数据面（journal、caps、subtree、dirfrag）付出更高代价，快照需客户端协作，性能与一致性权衡复杂。
延伸解读
“无状态 MDS”的准确理解
官方文档称 MDS 不在本地磁盘持久化元数据，但这不等于“无状态”。MDS 的权威持久态在元数据池的 journal 和 dirfrag 中，内存中的 MDCache 和 caps 只是可丢缓存。宕机后需通过 journal replay 重建，客户端未收到回复的请求要重发。因此，MDS 是可恢复状态机，而非无状态微服务，低估 failover 成本会导致排障误判。
多 active MDS 的适用条件
多 active MDS 并非越多越好。开启前需确认元数据热点可被空间切开，且迁移开销可摊销。否则，subtree 迁移的 barrier 税和跨 rank rename 的两阶段协调会引发 thrashing，反而降低性能。典型反例是 HPC scratch 或 CI 产物目录，大量小文件创建导致热点频繁迁移。盲目增加 max_mds 往往先买到震荡，而非线性扩展。
fsync 与 stat 的代价
CephFS 的 fsync 需脏数据落 OSD 并 ACK，再向 MDS 做 cap flush，两段往返叠加，比本机 fsync 贵一个数量级以上。频繁小 fsync 的数据库不适合直接部署。stat 在无有效 cap 时需走 GETATTR，大目录 ls -l 靠 readdir batch 摊薄，但精确 nlink 仍可能额外往返。这些元数据面代价是 CephFS 相对 RBD 的主要税负。
快照的客户端协作
CephFS 目录快照依赖 MDS 通知持 cap 客户端 flush，与 RBD 的 OSD 侧纯 COW 不同。快照一致性需要客户端诚实配合，硬链接跨 snap 边界的语义重建不完整是已知限制。因此，CephFS 快照更贴近用户可见的目录时间点，但一致性保障弱于 RBD；选型时需根据应用是否需要目录级时间点来决定。
Q&A
CephFS 中 MDS 的“无状态”是什么意思？
CephFS 的 MDS 并不在本地磁盘持久化元数据权威状态，而是将元数据变更写入 RADOS 上的 journal，因此常被口语化为“无状态 MDS”。但更准确地说，MDS 是可恢复状态机：权威持久态在元数据池（journal、dirfrag OMAP 等），热缓存和进行中请求在内存，本地磁盘不存权威副本。宕机后通过 journal replay 重建内存视图。
CephFS 的元数据池和数据池分别存储什么？
CephFS 至少有两个池：元数据池存储 inode、目录条目、MDS journal 等元数据；数据池存储文件内容对象。客户端数据 I/O 直接访问 OSD，不经过 MDS 转发。
MDS 故障后如何恢复？
MDS 故障后，standby MDS 会从 journal 的 expire_pos 开始 replay 未截断的日志，重建内存中的元数据视图。客户端未收到 reply 的请求需要重发，挂载会短暂阻塞。replay 时间与 journal 未 trim 量成正比，可通过 `ceph tell mds.{rank} flush journal` 强制 flush 来缩短恢复时间。
CephFS 中 subtree thrashing 是什么？如何缓解？
Subtree thrashing 是指同一目录在短时间内被多次 export/import，导致性能下降。常见诱因包括热点在深树上下游移、mds_bal_interval 过短、迁移本身抬高负载形成反馈放大。缓解方法包括调高迁移门槛、拉长采样间隔、将热点目录固定到特定 rank，而不是盲目增加 max_mds。
CephFS 的 capability 机制如何保证客户端缓存一致性？
MDS 向客户端发放 capability（cap），授权缓存或缓冲写。例如 Fc/Fr 允许缓存读，Fb/Fw 允许缓冲写，Fsx 表示独占写。持 Fb 的写客户端未 flush 前，其他客户端读同一文件会被阻塞（revoke 路径）。通过显式协议管理 cap，避免每次操作都询问 MDS，从而在分布式下逼近 POSIX 一致性。
CephFS 的 fsync 为什么比本地文件系统慢？
CephFS 的 fsync 大致串行：脏数据落到 OSD 并拿到 ACK，再向 MDS 做 cap flush，使 journal 落 RADOS。两段网络往返叠加，比本机 fsync 贵一个数量级以上。因此频繁小 fsync 的数据库不适合直接使用 CephFS。
CephFS 快照与 RBD 快照有什么区别？
CephFS 快照是目录级，需要客户端协作 flush（MDS 通知持 cap 客户端 flush），COW 落点在数据池对象和 MDS 快照元数据；RBD 快照是整 image，需要应用/fsfreeze 等 quiesce，COW 在 PrimaryLogPG snapset。CephFS 快照更依赖客户端诚实，RBD 快照更存储层自闭，两者不能互相替代。
CephFS 的挂载方式有哪些？各有什么特点？
CephFS 支持两种挂载方式：kclient（内核客户端）和 ceph-fuse（用户态 FUSE）。kclient 的 POSIX 完整度和性能更好，但特性跟随内核版本；ceph-fuse 可移植、易调试，但多一层 FUSE 路径。生产环境优先使用 kclient，容器无权限时才用 fuse。
