3FS系列(二):3FS元数据性能深度拆解:那些在技术文档中找不到的实现细节
- 2025-03-31 17:11:00
- 刘大牛 转自文章
- 240
系列文章目录
3FS系列(一):存储新纪元的开篇——3FS编译调优与部署的工程实践
3FS系列(二):3FS元数据性能深度拆解:那些在技术文档中找不到的实现细节
作为一家深耕高性能计算领域的AI科技公司,九章云极对 DeepSeek 开源的 3FS 分布式文件系统始终保持高度关注。在完成前篇所述的 3FS 编译与部署教学后,我们决定对3FS的元数据子系统展开深度评测。尽管 3FS 并不以元数据为最大卖点,但为使大家更好的了解 3FS ,我们基于 OPS (每秒操作数)、横向扩展性两个核心指标,结合 POSIX 接口完整性和元数据一致性验证,构建了多维度的评估体系,本文将详细阐述 3FS 的元数据性能测试过程及结论。
测试环境
部署方式
我们使用 3 台机器部署了一个 FoundationDB 集群,每台机器部署一个 FoundationDB 实例,其数据存储在一块 NVMe 盘上:
示意图中我们省略了 storage 集群和管理集群等其他服务。
机器硬件
部署服务的机器都拥有相同的硬件配置:
- CPU:
INTEL(R) XEON(R) PLATINUM 8558
- NVMe:
Dell DC NVMe ISE 7450 RI U.2 3.84TB
- NIC:
Mellanox CX7(400G IB)
测试软件
- pjdtest: master
- mdtest: v4.0.0
测试结果
1. POSIX 接口完善度
$ cd /mnt/3fs
$ prove -v /path/to/pjdfstest
接口操作 |
测试结果(成功数/总数) |
chflags |
14/14 |
chmod |
10/13 |
chown |
7/11 |
ftruncate |
15/15 |
granular |
7/7 |
link |
15/18 |
mkdir |
10/13 |
mkfifo |
6/13 |
mknod |
4/12 |
open |
20/26 |
posix_fallocate |
1/1 |
rename |
16/25 |
rmdir |
13/16 |
symlink |
11/13 |
truncate |
15/15 |
unlink |
13/15 |
utimensat |
8/10 |
总数 |
185/237 |
2. 元数据性能
2.1 目录深度小、单目录文件多
# 在根目录下创建 2 层目录,在每层目录下创建 3 个子目录,每个子目录下有 1 万个文件,总共 13 万个文件(分别测试 1、4、8、16、32 并发)
for i in 1 4 8 16 32; do mpirun --allow-run-as-root -np $i mdtest -z 2 -b 3 -I 10000 -d /mnt/3fs -u; done
进程数 |
Directory creation |
Directory stat |
Directory rename |
Directory removal |
File creation |
File stat |
File read |
File removal |
Tree creation |
Tree removal |
1 |
380.748 |
1824.665 |
272.056 |
340.216 |
370.860 |
1829.680 |
511.458 |
347.070 |
380.797 |
76.858 |
4 |
1381.670 |
6953.521 |
966.918 |
1171.964 |
1246.448 |
6786.223 |
1638.706 |
1164.522 |
305.848 |
63.135 |
8 |
2261.382 |
12465.725 |
1676.679 |
2004.064 |
2254.265 |
13131.568 |
3025.930 |
1926.433 |
193.340 |
32.531 |
16 |
3820.939 |
22851.152 |
2822.007 |
3074.238 |
3372.556 |
22338.285 |
4749.645 |
2698.098 |
92.800 |
16.526 |
32 |
6080.789 |
34035.724 |
3911.664 |
4503.779 |
4218.099 |
31594.211 |
5394.348 |
3702.021 |
65.353 |
9.037 |
2.2 目录深度大、单目录文件少
# 在根目录下创建 10 层目录,在每层目录下创建 2 个子目录,每个目录有 100 个文件,总共 204700 个文件(分别测试 1、4、8、16、32 并发)
for i in 1 4 8 16 32; do mpirun --allow-run-as-root -np $i mdtest -z 10 -b 2 -I 100 -d /mnt/3fs -u; done
进程数 |
Directory creation |
Directory stat |
Directory rename |
Directory removal |
File creation |
File stat |
File read |
File removal |
Tree creation |
Tree removal |
1 |
319.721 |
1618.960 |
201.003 |
328.875 |
370.162 |
1736.513 |
475.476 |
333.668 |
284.263 |
338.576 |
4 |
1347.497 |
6710.544 |
790.906 |
1139.578 |
1241.216 |
6534.494 |
1645.265 |
1098.005 |
358.543 |
277.418 |
8 |
2392.111 |
12583.666 |
1364.369 |
1971.815 |
2229.931 |
12535.251 |
2900.833 |
1833.398 |
301.977 |
222.741 |
16 |
3987.110 |
21620.244 |
2159.495 |
3093.048 |
3251.720 |
19826.121 |
4418.411 |
2709.684 |
243.149 |
152.085 |
32 |
5697.493 |
31619.125 |
3041.492 |
4256.970 |
3869.264 |
31431.703 |
5747.355 |
3517.754 |
167.188 |
84.271 |
3. 元数据一致性
我们将在 2 台机器 A、B 上挂载同一个文件系统,并顺序执行一些操作来验证元数据的一致性。
以下操作都在 3FS
的挂载点的根目录上执行。
特别需要注意的是,由于测试用例比较多,我们只挑选了 2 个导致不一致且有代表性的测试用例:
3.1 文件删除
A:
$ touch f1
B:
$ rm f1
A:
$ stat f1
File: f1
Size: 0 Blocks: 0 IO Block: 1048576 regular empty file
Device: 100028h/1048616d Inode: 41346824 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2025-03-18 10:34:47.000000000 +0800
Modify: 2025-03-18 10:34:47.000000000 +0800
Change: 2025-03-18 10:34:47.000000000 +0800
Birth: -
在节点 B 上删除文件 f1
后,节点 A 依旧能 stat
到文件,不符合预期。
3.2 文件读写
A:
$ echo 1 >> f1
$ cat f1
1
B:
$ echo 2 >> f1
$ cat f1
1
2
A:
$ echo 3 >> f1
$ cat f1
1
3
节点 A、B 轮流往文件 f1
写入一个数字,最后一次节点 A 写入数字 3 后,再次读取应该获得 1 2 3
,而目前获得的是 1 3
,不符合预期。
结论
基于系统性测试与分析,3FS在当前版本中展现出以下技术特性:
3FS
的POSIX
接口并不是很完善,并不能 100% 通过pjdtest
- 元数据性能并不是很强,但是其具有一定的扩展性
- 元数据的一致性目前来看是比较弱的,主要依赖内核的缓存超时(受
attr_timeout
、entry_timeout
配置项控制)。如果用户想在其他场景使用,可能需要调整缓存时长,牺牲一定的性能来换取一致性。
虽然 3FS
可能在元数据方面并不是很突出,但其通过一些措施(FFRecord 数据格式)在 AI 训练推理这样的场景下依旧获得很出色的性能。
此外,我们也可以得知在这样的场景下对 POSIX 接口完善度和元数据的一致性要求并不是很高。
(注:本评估严格基于实测数据,未引入推测性技术指标)
本次分享到此结束,若文中有细节描述不清晰或纰漏,欢迎随时关注九章云极公众号与我们探讨。每一条留言、每一次讨论,都在为技术的未来形态增添可能性。
文末彩蛋
最后,为大家呈现另一款通用性更高、成本更低的存储系统—— DataCanvas DingoFS分布式存储系统,该系统由北京九章云极科技有限公司开发,于2024年11月20日首次发表,并于2025年1月14日登记。DingoFS 因其高效的数据存储和管理、支持大规模数据的分布式存储、高可用性和可扩展性在业界独树一帜,更加适用于需要处理大量数据和要求高可靠性的应用场景。DingoFS 即将推出的新版将具备更佳的元数据性能。
DingoFS 核心特性如下:
- POSIX兼容性
提供与本地文件系统一致的操作体验,实现无缝系统集成
- AI原生架构
深度优化大语言模型工作流,高效管理海量训练数据集与检查点工作负载
- S3协议兼容
支持标准S3接口协议,实现对文件系统命名空间的便捷访问
- 全分布式架构
元数据服务(MDS)、数据存储层、缓存系统及客户端组件均支持线性扩展
- 卓越性能表现
兼具本地SSD级低延迟响应与对象存储级弹性吞吐能力
- 智能缓存加速体系
构建内存/本地SSD/分布式集群三级缓存拓扑,为AI场景提供高吞吐、低时延的智能I/0加速
我们是谁
提供本次实操教学的为九章云极研发人员。
九章云极,全称北京九章云极科技有限公司,2013年成立,致力于人工智能基础软件的规模化应用,融合了世界前沿的人工智能技术,以自主创新的“算力包”产品和智算操作系统为载体,为广大用户提供“算力+算法”一体化AI服务。
长按二维码,关注公众号领取免费算力包!
Alaya NeW算力云:让DeepSeek部署更简单!
借助 Alaya NeW算力云服务 提供的强大GPU资源,您可以轻松实现DeepSeek模型在云端的推理服务部署,并根据实际需求灵活使用算力,为技术创新与科研探索提供高效支持!
三步搞定一键部署,快速上手DeepSeek!
不想被复杂的配置流程困扰?别担心!只需三步,您就能轻松完成DeepSeek大语言模型的一键部署。立即行动起来吧!体验地址:
写在最后
- 作为分布式存储领域的实践者,我们在深度测试3FS后既感受到技术突破的惊喜,也窥见了工程化落地的挑战。这种复杂的技术观感,或许正是开源项目从实验室走向生产环境的必经之路。
- 若您在实践中有更精妙的参数调优方案,或是想深入探讨分布式存储的架构哲学,欢迎移步评论区 —— 或许下次我们就会一起探讨您提出的精彩观点。
下篇方向预告
400G 网络性能实测3FS

九章云极DataCanvas公司专注自动化数据科学平台的持续开发与建设,着重为数据科学家,AI从业者提供一整套开发平台,为政府和企业智能化升级和转型提供全面配套服务。
联系人: | 透明七彩巨人 |
---|---|
Email: | weok168@gmail.com |