从零开发分布式文件系统（四):一道经典面试题，深度对比 CephFS 与 3FS 的元数据架构优劣

书接上回

没想到，《从零实现分布式文件系统》系列文章已经写到第四篇了。

这个系列的初衷，源于之前一次面试中遇到的系统设计难题

•

这类问题往往最难准备，平时接触不多，一问就容易懵。

•

尤其是那些我们习以为常、认为“理所当然”的技术细节，在被深入追问时，却常常不知从何答起。

因此，接下来的文章会延续一个特点：

•

从一个日常可见的简单问题出发，从错误，误解开始。

•

一步步深入剖析，直到把背后的原理彻底讲清楚。

从零开发分布式文件系统(一) :100G读写带宽,百万IO请求文件系统怎么实现的

从零实现分布式文件系统(二) 如何在不升级硬件的前提下,小文件并发读写性能提升十倍

从零开发分布式文件系统(三) :JuiceFS｜沧海｜3FS 能相互替代吗?百万 OPS如何满足（1）(ceph 默认5 千)

从零开发分布式文件系统(三) :JuiceFS｜沧海｜3FS 百万 OPS 答疑（2）(ceph 默认 5 千)

不废话，直接用对话的方式直接开始

大纲:

描述查找/mnt/icfs/dir01/file.txt 过程？ 步骤拆分

•

如何查找文件inode ---元数据

•

如何查找文件数据---数据

不同系统不同存储方式： 问题变为：/mnt/icfs/dir01/file.txt 如何存储的

Ceph文件系统

•

文件的数据和元数据都是存储到RADOS对象

•

RADOS对象数据存储到裸盘，数据分配位置存储到KV中

•

必须有MDS节点，MDS必须缓存数据 ，不然无法访问文件

•

文件目录关系 是通过 每个目录建立对象，一级一级获取

•

ceph 元数据 有状态的，启动加载 复杂过程，维护缓存。

•

Dynamic Subtree Partitioning 就是不知道什么时候该分配 3FS文件系统

•

文件元数据存储到KV中 包括 文件目录项 和数据分布

•

3FS 文件元数据 无状态的，任意节点都查询。

•

文件目录关系 通过kv命名区分，记住存储kv数据库中。

•

3FS 文件元数据 无状态的，重启很简单。

然后回到 查找/mnt/icfs/dir01/file.txt ，Ceph如何落到具体MDS节点?

1. 面试官提问：

看你项目经历有实现过文件系统，

请描述查找/mnt/icfs/dir01/file.txt 过程？

2. 小青回答：

这个一定考察从客户端发起请求到 服务的端处理过程，

•

单机普通文件系统IO流程 从用户发起系统调用write操作，到VFS(虚拟文件系统）到具体的本地文件系统EXT4,这个，到内核，现在普通工程师不了解内核的，不会在这个地方过多回答。

•

针对分布式文件系统 也是具体文件系统 提供 网络文件系统NFS(Network File System)。首先它是用户空间实现文件系统 Filesystem in Userspace，

•

Fuse在用户空间实现文件系统，非内核态实现，s3fs就是采用 s3fs-fuse，

s3fs allows Linux, macOS, and FreeBSD to mount an S3 bucket via FUSE(Filesystem in Userspace). s3fs makes you operate files and directories in S3 bucket like a local file system，

•

FUSE：从内核到用户态的文件系统

图片摘自《To FUSE or Not to FUSE: Performance of User-Space File Systems》

图片摘自《To FUSE or Not to FUSE: Performance of User-Space File Systems》

1

VFS 路由操作 VFS 将系统调用操作路由到 FUSE 驱动。

2

创建请求并加入队列 FUSE 驱动创建一个 fuse_request 结构体，将其保存到内核的请求队列中。

3

进程阻塞 执行操作的当前进程会被阻塞。

4

FUSE 守护进程处理 FUSE 守护进程（daemon）从 /dev/fuse 中读取请求，将其从内核队列取出，并提交到底层文件系统（如 EXT4 或 F2FS）执行。

5

写回响应 操作完成后，FUSE 守护进程将回复（reply）写回 /dev/fuse。

6

标记完成与唤醒进程 FUSE 驱动将对应请求标记为已完成（completed），并唤醒之前被阻塞的用户进程

基于fuse实现一个分布式文件系统，后端存储可以其他系统

基于fuse实现一个分布式文件系统，后端存储可以其他系统

举例说明

举例说明

这个图的意思是：

1

背景：一个用户态文件系统，挂载点为 /tmp/fuse ，用户二进制程序文件为 ./hello ；

2

当执行 ls -l /tmp/fuse 命令的时候，流程如下：

1

IO 请求先进内核，经 vfs 传递给内核 FUSE 文件系统模块；

2

内核 FUSE 模块把请求发给到用户态，由 ./hello 程序接收并且处理。处理完成之后，响应原路返回

•

剩余客户端发送TCP等协议发送请求到服务端，就想http协议，服务端关注具体接口实现。【这个是错误理解】

3. 面试官评价：差评，不是 面试官想听的

和紫霞仙子想的一样一样的

我的意中人是个盖世英雄，有一天他会踩着七色的云彩来娶我。

我猜中了开头，可我猜不着这结局，

为什么“猜中开头，却猜不中结局”？

流程理解不完整

•

讲到 FUSE，只能说出客户端发请求的流程。

•

但对服务端如何处理、如何与底层存储交互，并不清楚。

•

实际项目中，大家更关注服务端设计与实现，而非客户端接入。

•

更重要的是，你从事的是后端开发，不是客户端开发。

停留在使用层，缺乏设计视角

•

习惯于使用现成方案，最初有过疑问，但因工作忙碌逐渐失去好奇。

•

即使知道元数据由多节点负责，也没有深入梳理过整体流程。

•

停留在模糊理解，实则是未真正掌握，缺乏主动探索的意识，也不好意思向同事请教，问题就此搁置。

总结：没有画出具体的流程图，仅凭模糊理解，其实并未真正掌握，甚至错误掌握

提示：请描述查找/mnt/icfs/dir01/file.txt 过程 还是没有开始，

面试官期望回答是什么？

•

路径遍历：查找过程是逐级进行的，每一步都解析一个路径分量。

•

权威 MDS：每个目录/文件都有一个“权威” MDS 负责管理其元数据，这实现了负载均衡。

•

动态子树分区：元数据分布（哪个 MDS 负责哪部分目录树）是动态的，可以根据负载情况自动调整（例如，热点目录可以被迁移到单独的 MDS 上）。

方案：根据范围拆分数据，中心化阶段存储数据落在具体tikv

优点：很容易理解，客户端之间去pd节点查询，一次操作完成

缺点：实现负载针对热点数据情况，不断迁移，影响业务，不过tidb在设计像细胞一样不断分裂，合并 代码实现负责。

4. 小白回答：那Tikv举例，需要数据拆分解决什么问题

PD (Placement Driver) Server：

是 TiDB 里面全局中心总控节点 整个 TiDB 集群的元信息管理模块， 负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构， PD 通过集成 etcd ，自动的支持 auto failover

方案：根据范围拆分数据，中心节点存储

优点：

•

很容易理解，当客户端查询时候，请求落在那个TIkv节点上，直接去PD节点查询即可

•

一次操作完成

缺点：

•

容易出现热点问题，需要支持像细胞一样不断分裂，合并 实现复杂

•

中心节点保证高可用，自己实现复杂，直接用etcd代替

•

为了维护全局元数据，需要每个tikv不断上报监控

疑问：为什么 TiDB 选择了中心化的 PD，而 Ceph 没有采用中心节点？

换句话说，为什么Ceph用中心节点存储元数据

1

数据模型不同

•

TiDB：本质是数据库，数据按 Key-Range 拆分，范围连续、元信息量相对可控。 → 中心节点（PD）只需要维护 Region 边界、Leader 信息，几万到几十万条记录就够，中心节点可hold住。

•

Ceph：面向对象存储，数据量可能是 十亿级对象。 → 如果用中心节点存所有对象的元数据，节点会被 元信息洪水冲垮（规模远超 TiDB）。

1

中心节点的高可用成本

•

TiDB 的 PD 节点很少（3-5个），借助 etcd 共识协议就能搞定。

•

如果 Ceph 要有中心节点，必须存储数十亿对象的映射关系，还要强一致、可扩展 → 存储、同步、容错开销巨大。

1

元数据维护开销

•

TiDB：Region 心跳（每几秒一次），规模有限。

•

Ceph：如果每个 OSD 节点都向中心汇报数十亿对象的状态 → 中心节点会直接爆炸。

•

所以 Ceph 选择了 分布式心跳+CRUSH映射，元数据天然“下沉”到客户端算法和 OSD 自身。

1

为什么不是“直接 KV 查询”？

•

语义复杂：文件系统不是简单 KV，涉及路径解析、权限检查、递归目录遍历、锁语义等，必须通过 MDS 来“理解”操作语义。

•

一致性要求：

•

多客户端并发时，MDS 必须协调锁（比如一个 client 在 rename，另一个在 stat）。

•

单纯的 KV 查询无法提供这种强一致、分布式锁保障。

Ceph 的设计取舍

•

对象层：走去中心化（CRUSH），解决了“数十亿对象”的扩展性问题。

•

文件系统层：走中心化（MDS），因为文件系统操作（ls、rename、mkdir）需要全局一致的目录树，没法用纯算法算出来。

5. 面试官点评：

请描述查找/mnt/icfs/dir01/file.txt 过程 还是没回答要点

•

大量小文件文件系统，不适合中心化存储，怎么存储呢？

•

数据定位元数据（对象 → OSD） 没有中心节点，完全依赖 CRUSH 算法，客户端本地算 过程呢？扩缩容如何处理

•

文件目录查询和数据查询不一样，需要递归遍历方式

•

CephFS 的 MDS（Metadata Server），它是中心化的，MDS 负责维护：目录树、文件 inode、权限、布局信息等，如何查找呢，扩缩容如何处理

上面业务描述 怎么转换成技术语言

请描述查找 /mnt/icfs/dir01/file.txt 的过程，目前仍未切中要点：

•

大量小文件的文件系统并不适合中心化存储，那么该如何存储？

•

数据定位元数据（对象 → OSD）并没有中心节点，完全依赖 CRUSH 算法由客户端本地计算，那么具体过程如何？扩缩容时又如何处理？

•

文件目录查询与数据查询并不相同，需要通过递归遍历的方式完成。

•

CephFS 的 MDS（Metadata Server） 是中心化的，负责维护目录树、文件 inode、权限及布局信息。那么在查找时具体是如何工作的？扩缩容时又如何应对？

6. 小黄回答：从数据结构角度如何存储一个文件系统元数据（目录树）

6.1 3FS 元数据模的设计与 CephFS 的不同之处

吊打面试官03:如何设计一个内存文件系统（多级目录）

一个文件系统通过表存储

CREATETABLE categories (  
  category_id INT PRIMARY KEY,  
  parent_id   INTNULL,  
  category_name TEXTNOTNULL,  
FOREIGNKEY (parent_id) REFERENCES categories(category_id)  
);

通过递归方式查询一个完整文件路径，直接去数据库查询可以了，简单方便。

这就是基本原理，请看看其他系统是不是按照这个思路设计的

这里对比Ceph 和3FS设计

ceph 元数据设计

1

2010年：Ceph开始引入RADOS（可扩展自组织分布式对象存储）作为其核心存储技术，并发布了Ceph的第一个稳定版本。

2

2012年：Ceph在Linux内核中引入了RADOS Block Device（RBD）模块，从而支持块存储。这是Ceph变得更加多样化并用于虚拟化和云存储的重要一步。

3

2013年：Ceph的文件系统组件CephFS引入，使其成为一个全面的存储解决方案，包括对象存储、块存储和文件存储。

Ceph核心是RADOS， 根据 Ceph: A Scalable, High-Performance Distributed File System 描述

RADOS 设计目标是存储文件中的数据对象方式存储（块存储）， 对象和对象直接是扁平化结构，没有没有文件系统概念（刚开始不是为文件系设计的），

后来又CephFS出现文件系统，他怎么设计， 原来架构不变，文件元数据 目录项目 对象方式存储磁盘（和普通文件系统一样，目录项目存储磁盘）， rockdb引擎是存储对象的的对象的元数据，不是文件系统

因此文件系统元数据不是直接存储到kv中， 基于这样结果你想想 ，每个目录都是对象，无数目录对象方式存储

RADOS对象

RADOS对象

RADOS对象与RocksDB的关系

RADOS对象的定义

Ceph OSD Daemons store data as objects in a flat namespace. 

This means that
objects are not stored in a hierarchy of directories. 
An object has an
identifier, binary data, and metadata consisting of name/value pairs

RADOS对象是Ceph存储系统中的基本存储单元，每个对象包含三个组成部分：

•

对象ID - 唯一标识符

•

二进制数据 - 实际内容

•

元数据 - 属性信息

在BlueStore中的存储分层如下：

1

RADOS对象数据 - 直接存储在原始块设备上

2

对象元数据 - 存储在RocksDB中，

•

对象名称到磁盘位置的映射

•

分配信息

•

其他内部元数据

文件的元数据不是存储在RocksDB中，存储元数据的对象存储的元数据存储在RocksDB中

Ceph的 文件系统元数据必须 MDS 管理，不然无法形成一棵树

元数据 与MDS关系维护

MDS节点的元数据虽然最终存储在RADOS元数据池中， 元数据池包含：

•

文件和目录的inode信息

•

目录项(dentries)

•

文件系统层次结构

•

MDS日志、会话表等管理信息

但在MDS内部通过rank-based的对象命名和分片机制进行组织

目录片段(Directory Fragments)

目录内容通过目录片段进行分布，可以看到具体的获取方式

目录片段对象命名格式为{dir_ino:x}.00000000，其中dir_ino是目录的inode号。

查看名为vdb.1_1.dir（目录下有100万个文件）的目录的inode号为1099511627788，转换为16进制为1000000000C

[root@node2 cephfs]# rados -p cephfs-metadata ls

根目录的inode信息，存放在1.00000000.inode对象当中。

MDS 通过以下方式管理目录结构：

•

CDir 对象：表示目录 MDCache.h:32-34

•

CDentry 对象：表示目录项 MDCache.h:32-34

•

CInode 对象：表示文件或目录的 inode MDCache.h:32-34

3FS 元数据服务架构设计

文件的 Inode 和 Dentry结构

键值模型映射

与 CephFS 的比较

CephFS 的元数据管理与 3FS 有显著不同。 在 CephFS 中，元数据由 Ceph 文件系统的元数据服务器（MDS）管理 。MDS 负责处理文件和目录的元数据操作，如路径解析、权限检查和目录结构维护。CephFS 支持多个 MDS 实例，以实现负载均衡和高可用性。

CephFS 的 MDS 通过将文件系统的命名空间划分为多个子树（subtree），并将这些子树分配给不同的 MDS 实例来管理元数据负载。

这种方式使得 CephFS 能够在多个 MDS 实例之间分配元数据负载，从而提高性能和可扩展性。

3FS 的元数据管理

在 3FS 中，元数据服务是无状态的，所有元数据存储都依赖于 FoundationDB 等分布式事务性键值数据库。

这种设计使得元数据服务能够高效地处理文件系统的元数据操作，并支持大规模的并发访问。

3FS 的元数据服务通过查询 FoundationDB 来获取所需的元数据。 由于 FoundationDB 提供了强一致性和事务支持，3FS 能够确保元数据操作的原子性和一致性。

6.2 举例说明创建文件

/mnt/icfs/dir01/file.txt 文件，ceph和3fs 在kv中如何 indoe，目录项，目录这些关系

理解 Ceph 和 3FS 如何将文件系统元数据映射到底层键值存储，是掌握其设计精髓的关键。下面我们通过创建 /mnt/icfs/dir01/file.txt这个具体例子，来对比它们的设计哲学和实现差异。

CephFS 的 KV 存储实现

CephFS 将文件和目录的元数据以对象的形式存储在 RADOS 元数据池中。 其核心思想是一个目录对应一个或多个 RADOS 对象， 该目录下的所有文件和子目录信息（目录项，dentry） 则存储在这个目录对象的 OMap（一个键值对集合）中。

创建 /mnt/icfs/dir01/file.txt的过程大致如下：

1

分配 Inode：系统为路径中的每个组成部分分配唯一的 inode 编号。

2

创建目录项：

•

在根目录对象（如 1.00000000）的 OMap 中，创建键为 mnt的条目，值包含目录 mnt的 inode 信息。

•

在 mnt目录对象（如 {mnt-inode}.00000000）的 OMap 中，创建键为 icfs的条目，值包含目录 icfs的 inode 信息。

•

在 icfs目录对象（如 {icfs-inode}.00000000）的 OMap 中，创建键为 dir01的条目，值包含目录 dir01的 inode 信息。

•

在 dir01目录对象（如 {dir01-inode}.00000000）的 OMap 中，创建键为 file.txt的条目，值包含文件 file.txt的 inode 信息（如权限、大小等）。

3

存储文件数据：

•

文件 file.txt的实际内容会被切分成多个对象（如 {file.txt-inode}.0, {file.txt-inode}.1）

•

存储在 RADOS 的数据池中。

文件的 Inode 和 Dentry结构

3FS 的 KV 存储实现

3FS 的设计更显简洁和数学美感。

它直接将所有元数据存放在全局有序的 FoundationDB 中，

同样创建 /mnt/icfs/dir01/file.txt，在 3FS 中会发生：

1

分配 Inode：系统分配全局唯一的 inode 编号。

2

构造并存储键值对：

•

目录项：每一级路径都创建一个 dentry 键值对。

•

键：DENT{父目录inode编号}{条目名}

•

（例如 DENT1mnt, DENT{mnt-inode}icfs, DENT{icfs-inode}dir01, DENT{dir01-inode}file.txt）

•

值：目标 inode 的编号。

•

Inode：为每个文件或目录创建一个 inode 键值对。

•

键：INOD{inode编号}，其中 inode 编号采用小端字节序编码，目的是打散数据，避免热点。

•

值：文件或目录的属性（权限、大小、时间戳等）。

7.在此聚焦ceph查询过程

7.1 数据结构

这个图还是不清楚

这个图还是不清楚

7.2 客户端无缓存 查找过程

1

起点：连接根目录

客户端首先会连接到一个已知的MDS。 这个MDS可能恰好是根目录 /的“权威MDS”， 也可能不是。 根目录的权威MDS通常是预先确定的 MDS0 。

2

逐级遍历路径

查找过程会沿着路径 /mnt/icfs/dir01/file.txt逐级进行：

•

接收到客户端请求的MDS（我们称为接收MDS）首先会检查第一级目录 mnt的权威MDS是谁。

•

如果 mnt目录的权威就是自己，接收MDS会直接查询本地的元数据缓存。

•

如果 mnt目录的权威是另一个MDS（比如MDS-2），接收MDS会将这部分查找请求转发给MDS-2。

•

MDS-2 作为 mnt目录的权威，会解析其下的 icfs目录项。

•

同样地，它会判断 icfs目录的权威MDS是谁。

•

这个过程会一直重复，直到找到最终文件 file.txt的inode信息。

3

返回结果

•

一旦找到 file.txt对应的inode，这个信息会沿着MDS转发链原路返回最终送达客户端。

•

客户端获得inode后，就可以直接与OSD（对象存储守护进程）交互，读写文件数据

说明：

客户端无法直接文件计算落在那个MDS

客户端计算文件名 hash → 落在哪个 frag（dirfragtree） → 查 fragmap 找 MDS rank → 请求发过去。

这个依然是查找 在 fragmap 查 frag 这个缓存信息，而不是通过hash直接计算的

为什么要分片 (fragmentation)

•

目录可能非常大（比如百万文件），单个 MDS 扛不住。

•

所以 CephFS 把目录拆成多个 frag (片段)，不同 frag 可以交给不同 MDS 管理。

•

每个 frag 的范围由 frag_t 描述。

2. hash 如何计算

1

对 dentry 名字做 hash

•

比如：

•

frag0: [0x00000000, 0x3fffffff] → rank0

•

frag1: [0x40000000, 0x7fffffff] → rank1

•

frag2: [0x80000000, 0xbfffffff] → rank2

•

frag3: [0xc0000000, 0xffffffff] → rank3

•

那么 hash("file.txt") 可能落到 0x45ab1234，属于 frag1，对应 MDS rank1。

3. frag_t 是什么

frag_t 本质上就是一个 区间标识，由：

•

位掩码（mask）：表示切分深度（多少个区间）。

•

起始值：表示当前 frag 在树中的位置。

例如：

•

frag = 0/1 → 覆盖所有 hash 值（整个目录未拆分）。

•

frag = 0/2 → 表示 hash 空间前半部分。

•

frag = 1/2 → 表示 hash 空间后半部分。

继续切分：

•

frag = 0/4, 1/4, 2/4, 3/4 → 四等分。

4. MDS 如何维护 fragmap

•

fragmap：frag_t → MDS rank 的映射表。

•

当某个目录太大，MDS 会发起 split，把一个 frag 拆成两个子 frag，可能迁移其中一部分给其它 MDS。

•

这个信息存储在：

•

MDS 内存（运行时 authority 表）

•

同时 journal 写到 metadata pool，保证崩溃恢复后还能重建。

MDS内部结构 并不维护文件和mds关系

•

MDSMap、Subtree Map、Fragmap

7.3 为什么：客户端获得inode后，就可以直接与OSD（对象存储守护进程）交互，读写文件数据

All file data in CephFS is stored as RADOS objects. 

CephFS clients can directly
access RADOS to operate on file data.

MDS only handles metadata operations.

不获取元数据 客户端不能直接访问数据了吗？

文件数据到对象的映射

文件数据以<inode number>.<object index>的格式存储为RADOS对象。

CRUSH映射包含存储设备的层次结构，反映物理组织：

典型的故障域层次包括：

•

device - 单个OSD设备

•

host - 主机级别

•

rack - 机架级别

•

row - 行级别

•

room - 机房级别

•

datacenter - 数据中心级别

动态故障恢复

当OSD故障时，CRUSH算法会自动重新映射数据 CRUSH会：

•

检测故障的OSD

•

将PG重新映射到健康的OSD

•

触发数据迁移和恢复过程

总结：

3FS

3FS

•

kv 存储依然是 去中心节点查询，但是元数据无状态的，不需要维护缓存

ceph

ceph

•

Ceph基于动态子树分割（Dynamic Subtree Partitioning）来将文件系统目录结构分散到MDS（MetaData Server）即元数据集群中。维护缓存

CephFS的元数据负载均衡是一个复杂的分布式系统， 涉及多个组件协同工作。 MDBalancer负责决策，Migrator执行迁移，MDCache`维护缓存， 而日志系统确保一致性。

当目录结构发生变化时，系统通过权威性机制和日志恢复来保证客户端能够正确找到目录位置。 具体什算法，不明确，客户端是无法计算的，必须去中心节点查询

•

无中心节点 分配，必须考虑 节点故障

课后作业

•

MDS 是单线程，为了简化锁机制、保证目录树一致性，性能为什么不高、

•

假如遍目录 /mnt/icfs/dir01/file.txt

目录：/ ---mds0 目录：mnt--mds1

目录：icfs--mds2 目录：dir01--mds3

一次查询怎么跨这么多节点， 如何优化

参加书籍（电子书）

•

To FUSE or Not to FUSE: Performance of User-Space File Systems

•

https://www.qiyacloud.cn/2021/06/2021-06-21/

•

https://www.qiyacloud.cn/2021/05/2021-05-31/

•

https://www.qiyacloud.cn/2021/05/2021-06-07/

•

https://deepwiki.com/ceph/ceph

•

pd server 和etcd之间什么关系？

•

https://github.com/manuel71sj/deepseek-ai_3FS/blob/main/docs/design_notes.md

•

https://ceph.io/assets/pdfs/weil-ceph-osdi06.pdf

•

Cephfs的MDS侧元数据池和mdcache存储数据结构分析

•

File Systems Unfit as Distributed Storage Backends:Lessons from 10 Years of Ceph Evolution