为什么 CephFS 要拆开元数据路径和数据路径

这篇文章关注的不是 MDS 或 OSD 的定义，而是 CephFS 为什么不能把文件系统请求都塞进一条统一路径里，以及元数据和数据路径分离后分别换来了什么扩展性、性能和复杂度代价。

如果只从“文件系统对外提供的是统一目录树”这个表象出发，一个很自然的想法是：既然用户看到的是同一个命名空间，那 CephFS 为什么不把所有请求都交给同一种后端角色处理，反而要把元数据路径和数据路径显式拆开。这个问题的关键在于，文件系统里的“统一视图”并不等于内部所有动作都是同一种工作负载。路径解析、权限判断、目录项变更、inode 状态维护和租约撤销，本质上是强语义、强顺序、强协调的问题；大块数据读写、条带分布、对象持久化和副本复制，则更像吞吐优先、并行优先、去中心化扩展的问题。把这两类工作硬塞进同一条路径，CephFS 很快就会在语义和扩展性之间两头受限。

先看如果不拆会发生什么。假如所有文件操作都必须穿过同一个中心角色，无论是 lookup、rename 还是大文件顺序写，都先由它来接收、判定再转发，那么这个角色就会同时承担两种完全不同的压力。一方面，它必须对目录树和 inode 语义保持足够强的掌控，确保谁拥有写权限、哪个目录项刚刚被改名、哪个客户端手里还有缓存授权这些信息不会乱掉。另一方面，它还会被迫站到大流量数据面中间，承接本来可以直接并行扩展的读写吞吐。结果就是：要么它为了守住语义而成为性能瓶颈，要么它为了提高吞吐而放松中心控制，最终把文件系统语义搞得不稳定。

CephFS 之所以把元数据路径交给 MDS，本质上是在承认一件事：文件系统里有一部分工作天然需要一个对命名空间状态“知道得最多”的协调中心。客户端要访问一个文件，首先不是去问“数据块在哪”，而是要先回答“这个路径是否存在”“我看到的是哪个 inode”“我是否有权限”“当前目录或文件是否正处于别的元数据操作中”。这些问题都无法通过简单地把对象散到 OSD 上来解决，因为对象存储可以很好地保存数据，却并不天然理解目录树、链接关系、重命名原子性和缓存授权撤销这些文件系统语义。也就是说，元数据路径被单独拿出来，并不是为了增加层次，而是因为命名空间一致性本身就是一个必须集中协调的问题。

但如果 MDS 不仅负责命名空间语义，还要亲自转运和串行化所有数据 I/O，那么 CephFS 又会失去最重要的扩展能力。大文件读写的理想路径，恰恰应该尽量绕开中心元数据服务，让客户端在拿到必要元数据和授权之后，直接与底层 RADOS/OSD 数据面交互。只有这样，数据流量才能沿着对象分布并行展开，而不是全部挤过 MDS。这就是数据路径独立出来的根本原因：元数据的中心化协调是为了守住语义，而数据面的去中心化并行是为了守住吞吐和规模。如果不把两者拆开，CephFS 要么更像一个只能小规模扩展的集中式 NAS，要么就不得不在一致性要求上不断让步。

从真实访问过程看，这种拆分很容易理解。客户端面对一个文件操作时，通常先沿着元数据路径完成定位和授权，再沿着数据路径完成实际 I/O。也就是说，MDS 更像是先回答“你访问的是谁、你能不能这么做、当前应该按什么视图理解这个文件”，而 OSD 数据面再回答“这些数据对象在哪里、如何并行读取或提交、如何复制到持久化后端”。前者解决的是语义归属，后者解决的是数据搬运。CephFS 把这两条路径拆开，不是为了让架构看起来更复杂，而是为了避免让“语义判断者”同时变成“所有字节流量的搬运工”。

这类拆分还有一个更深的背景：元数据和数据的热点形态根本不同。元数据热点往往集中在少数目录、少数 inode、少数重命名或创建删除密集区域，它们的瓶颈更像锁竞争、状态协调和缓存回收。数据热点则更像带宽、对象布局、条带大小和副本写放大的问题。如果让一条统一路径同时处理这两种热点，系统很难针对性优化。拆开之后，MDS 可以重点围绕目录树组织、会话状态和 capability 撤销来优化，数据面则可以围绕对象分布、并发 I/O 和 OSD 路径来扩展。这种“不同类型压力由不同平面承担”的设计，正是 CephFS 能同时维持文件系统语义和对象存储扩展性的基础。

当然，拆分从来不是白拿收益。元数据路径和数据路径一旦分开，客户端就会同时持有两类状态：一类是来自 MDS 的命名空间视图和缓存授权，另一类是与底层数据对象访问相关的映射和 I/O 上下文。这样做的代价是，系统必须在“元数据刚刚变化”和“客户端仍在访问旧数据路径”之间维持更细致的一致性协议。例如重命名、截断、权限变化、缓存失效、会话回收等场景，都不再只是某个中心节点本地更新一个表项那么简单，而是要跨客户端、MDS 和 OSD 数据面共同收敛。也正因为如此，CephFS 后续才会需要 capability、会话状态、日志回放和多 MDS 迁移等一整套额外机制，去弥合这条拆分后自然出现的边界。

这也解释了为什么 CephFS 的复杂度并不只是“多了一个 MDS”。真正让它复杂的，是它既想保留 POSIX 风格文件系统的命名空间语义，又想借用 Ceph 底层对象存储的水平扩展能力。前者要求某些状态必须集中判断，后者要求大部分数据流量必须尽量分散。元数据路径和数据路径的分离，本质上就是在这两种要求之间做出的架构妥协。你可以把它理解成一种职责交换：系统接受更多协调复杂度，换取不让 MDS 成为数据吞吐总瓶颈；系统接受更多一致性协议，换取客户端能够更直接地利用底层并行数据面。

所以，CephFS 之所以要拆开元数据路径和数据路径，不是因为“目录信息”和“文件内容”在概念上不同，而是因为它们对应的是两种完全不同的系统问题。元数据路径负责维护统一命名空间下的语义正确性，数据路径负责释放对象存储层的并行扩展能力。只要 CephFS 既想做“真文件系统”，又想建立在分布式对象存储之上，这种拆分几乎就是必然选择。它真正解决的，不是抽象上的整洁，而是如何在不牺牲文件系统语义的前提下，让数据流量不被中心元数据服务压死。

进一步讨论

• 【待展开：为什么 CephFS 文件数据可以绕过 MDS 直达 OSD｜cephfs-data-bypasses-mds】：这能继续展开客户端何时必须先经元数据授权、何时又能直接利用底层对象数据面。