RustFS 统一存储 — 完整设计开发计划（中文版）
RustFS 统一存储 — 完整设计开发计划（中文版）
文档编号: RUSTFS-PLAN-001(总执行计划)
状态: 草案
版本: 1.0.0
权威设计: RUSTFS-MD-DESIGN-005(全新构建,无迁移)
支撑文档: FEAT-001、LLD-001(I/O 栈)、LLD-002(随机读)、
MD-DESIGN-001/002(元数据)、MD-DESIGN-003(xl.meta——已废止)
语言: 中文 (English mirror: rustfs-dev-plan-EN.md)
1. 项目概述
1.1 目标
在全新代码库上构建云原生统一存储平台,通过单一命名空间对同一份数据提供:
- 文件(POSIX)——高带宽、低延迟,针对 AI "一次写入、多次 fseek/fread" 负载优化。
- 对象(S3)——完整 S3 兼容 API。
- 块——经 iSCSI 与 NVMe-oF 的 VM / 裸金属磁盘。
1.2 架构(最终,源自 DESIGN-005）
无状态 MDS + 事务型 KV + 公式驱动布局
数据面客户端 ↔ chunk 直连(MDS 永不在数据路径上)
chunk 服务把经验证的 RS / bitrot / 磁盘 / heal 作为库复用
无迁移、无 xl.meta、无共存——系统只见自己的格式
1.3 非目标(v1)
✗ 去重(暂缓——需全局内容索引;破坏简洁性)
✗ 与任何旧 on-disk 格式的向后兼容(全新构建)
✗ 多区域双活(后续;v1 为单区域 + 异步复制)
2. 组件 / Crate 映射
Crate / 模块 职责 track
──────────────────── ────────────────────────────────────── ─────
rustfs-kv TransactionalKv trait;内嵌 A(元数据)
(redb/RocksDB)+ TiKV 后端
rustfs-inode InodeAttr、Layout、DentValue、Volume、 A
ExtentEntry、键编解码
rustfs-placement HRW 放置、ClusterMap、偏移→chunk 换算 A(A+C 共享)
(MDS 与客户端共享)
rustfs-mds 无状态元数据服务;文件系统语义事务; A
inode 区段分配器;gRPC
chunk-format on-disk chunk 格式规范 + 编解码 B(数据)
(自校验内联 bitrot)
chunk-store 全新 ChunkStore:chunk-key 寻址, B
复用 RS/bitrot/磁盘/heal 库
packing 小文件打包:容器管理(append/seal)、 B
Slice 指针、打/解包、压实 GC。容器即大的
内部文件 → 复用 chunk-store。
ecstore-core(复用) Reed-Solomon 编解码 B(既有)
bitrot(复用) 流式 HighwayHash bitrot B(既有)
disk-io(复用/新) io_uring 磁盘引擎 + 缓冲池 B
heal(复用) 重建数学 B(既有)
rustfs-client 客户端内核:放置、集群映射缓存、 C(客户端)
元数据缓存、重试/对冲、熔断、chunk 传输
rustfs-fuse FUSE 挂载;预读(顺序)+ 随机读路径; C
无租约缓存
s3-frontend 构建于 MDS + ChunkStore 之上的 S3 API C
block-frontend 卷管理(EXTM、精简/COW)、iSCSI、 C
NVMe-oF target
rustfs-rdma RDMA 数据面传输 D(平台)
obs / metrics(复用) OpenTelemetry + Prometheus D
test-harness 一致性 + 混沌 + 基准 测试台 D
3. 开发 Track(可并行)
Track A — 元数据 rustfs-kv、inode、placement、mds
Track B — 数据 chunk-format、chunk-store、packing(+ 复用 RS/bitrot/磁盘/heal)
Track C — 客户端 client、fuse、s3-frontend、block-frontend
Track D — 平台 rdma、可观测性、HA、测试、基准
Phase 0 之后,A 与 B 并行;C 在 A+B 暴露稳定 API 后启动;D 的测试台从 Phase 1 起 持续运行,性能/RDMA 置后。
4. 分阶段计划、里程碑、验收
Phase 0 — 设计冻结与脚手架 (M0)
确定开放问题(DESIGN-005 §6):
Q1 KV 后端:先内嵌 redb/RocksDB;HA 用 TiKV。
Q2 inline_threshold(默认 16 KiB;按后端上限)。
Q3 on-disk chunk 格式规范(stripe_unit、内联 bitrot 块、chunk-key 路径)。
Q4 默认存储策略(数据集用 EC k+m;块/小文件用副本)。
Q5 ChunkStore = 全新薄存储(确认),复用 RS/bitrot/磁盘/heal。
搭建:
· 单仓 crate 骨架、CI(构建/测试/lint/覆盖率)、特性开关
· Protobuf 线协议契约(MDS gRPC、ChunkStore gRPC、GetClusterMap)
· chunk-format 规范文档 + 黄金测试向量
· 测试台骨架(一致性/混沌/基准占位)
M0 验收:所有 crate 骨架在 CI 通过;protobuf + chunk-format 规范评审并冻结;
Q1–Q5 已决策并记录。
工作量:约 1 个月。
Phase 1 — 元数据内核 (M1) [Track A]
交付:
· rustfs-kv:TransactionalKv trait + 内嵌后端;SSI 语义;CAS
· rustfs-inode:全部类型 + 键编解码 + 序列化
· rustfs-placement:对集群映射做 HRW;偏移→chunk;确定性 dist/path
· rustfs-mds:inode 区段分配器;create/lookup/getattr/setattr/mkdir/
rmdir/readdir/rename/unlink/link/symlink/xattr 各为单次 KV 事务;
OpenLayout、GetClusterMap、CommitWrite、卷 RPC(可桩);gRPC 服务端
· VIDX 版本行;PEND/DELQ 行定义
M1 验收:
· 全部元数据操作在内嵌 KV 上通过单元 + 集成测试
· 跨目录 rename 原子(事务测试)
· readdir 为单次范围扫描;lookup/getattr 单次 get(性能断言)
· 崩溃测试:操作中途杀 MDS → 重启后 KV 一致
工作量:约 2.5 个月。
Phase 2 — 数据面 / chunk 服务 (M2) [Track B]
交付:
· chunk-format:自校验 on-disk 格式;编解码;黄金向量通过
· disk-io:io_uring 引擎(逐盘 ring、固定缓冲)+ tokio::fs 兜底
· chunk-store:write_chunk/read_chunk/delete_chunk(chunk-key、字节范围);
复用 RS 编解码;读时内联 bitrot 校验;分片损坏/缺失时 heal 重建
· packing:容器管理(open/append/seal)、Slice 读路径、按容器 CMTA
(dead_bytes)、压实 GC;容器即大的内部文件,复用 chunk-store + 公式布局
· 放置集成:chunk_set/path/dist 与 MDS 计算完全一致
· 新 file_id 的 PEND 写意图;孤儿 GC 巡查器;DELQ chunk GC
M2 验收:
· 写一个 chunk,按任意字节范围读回,逐字节一致
· 在盘上损坏一个分片 → 仍能经重建读取成功;heal 修复
· 客户端与 MDS 对 10^6 个随机 key 计算出完全一致的位置
· 4 KiB 读的 EC 部分读放大 < 1.2x(LLD-002 目标)
· 把 10^6 个小文件打包进容器;经 Slice 逐个读回;删除后压实回收空间
(KV 无数据本体;验证 KV 仅存元数据)
工作量:约 3.5 个月(与 Phase 1 尾部重叠)。
Phase 3 — 客户端 + FUSE(POSIX MVP) (M3) ★ 关键可用里程碑 [Track C]
交付:
· rustfs-client:放置引擎、集群映射缓存、元数据缓存(基于 version、
close-to-open)、重试/退避、对冲读、熔断、chunk 传输(先 gRPC,后 io_uring TCP)
· rustfs-fuse:open/read/write/seek/close/stat/readdir/mkdir/rename/unlink/
truncate/fsync;内联小文件快路径
· 预读引擎(顺序 + 跨步检测)
· 随机读路径:open 时取全量 chunkmap、片段缓存(TinyLFU)、高 QD 路径;
尊重 posix_fadvise
· 崩溃一致性:先数据后 CommitWrite;PEND 生命周期
M3 验收:
· 挂载;dd 1 GiB 写 + md5 读回;ls -la;cp;rename;rm
· "一次写入、多次 fseek/fread":fio randread > 目标 IOPS;p99 达标
· 顺序读接近 DSS 聚合带宽(预读生效)
· 多进程读者(模拟 DataLoader)open 后读取不再打 MDS(无租约 version 缓存生效)
工作量:约 3 个月。
Phase 4 — S3 统一命名空间 (M4) [Track C]
交付:
· s3-frontend:PutObject/GetObject/DeleteObject/ListObjects(V2)/HeadObject;
分段(暂存 parts → Complete 时写 formula chunk);范围 GET;条件请求;
对象标签;桶操作
· 桶↔目录映射(/buckets/<bucket>/<key>);ListObjects = readdir
· 经 VIDX 的版本
M4 验收:
· s3-tests 一致性套件通过(核心 + 分段 + 版本子集)
· 经 S3 写入的数据可经 FUSE 挂载读取,反之亦然(同一 inode)
· 10^7 对象桶的 ListObjects 为每目录 O(1)(延迟证明)
工作量:约 2 个月。
Phase 5 — 块存储 (M5) [Track C]
交付:
· block-frontend 卷管理:EXTM 区段映射;精简配置;COW 快照;克隆;扩容
· NBD 服务(最简,供测试)→ iSCSI target(生产)→ NVMe-oF
· 写顺序 WAL;SYNCHRONIZE_CACHE/flush 语义;UNMAP/TRIM
M5 验收:
· 创建卷;经 iSCSI 挂载;从中引导一台 QEMU/KVM 虚机
· 快照 + 克隆 + 扩容验证;虚机 fsync 后数据一致
· 4 KiB 随机写延迟达标(LLD-001)
工作量:约 3 个月。
Phase 6 — HA 与横向扩展 (M6) [Track A + D]
交付:
· rustfs-kv 的 TiKV 后端(集群、分布式事务)
· 负载均衡 / 客户端轮询后多个无状态 MDS;会话故障转移
· 集群映射 epoch 变化 → 公式重定位 → 在线再平衡
(copy-then-switch,限速);节点增删;节点丢失时 heal
M6 验收:
· 负载下杀一个 MDS 实例 → 客户端故障转移,无错误外泄
· 增加一个节点 → 数据在线再平衡,客户端 I/O 影响 < 10%
· KV 元数据操作随 MDS 实例数近线性扩展(mdtest)
工作量:约 2.5 个月。
Phase 7 — 性能与加固 (M7) [Track D]
交付:
· RDMA 数据面传输(读用 READ 拉取,写用 WRITE 推送);
传输协商(RDMA → io_uring TCP → gRPC)
· io_uring 调优:SEND_ZC、IOPOLL 随机读 ring、NUMA 绑定
· 随机读:访问计划提示 API + 框架 shim;DSS 热片段层
· FUSE-over-io_uring(内核 ≥ 6.14)带兜底
· (可选)GPUDirect Storage 路径
M7 验收(LLD-001/002 目标):
· 4 KiB 随机读 p50 < 15 µs(RDMA),p99 < 50 µs
· 随机读 > 500 K IOPS/客户端(RDMA、EC 部分读)
· 带访问计划的乱序 epoch 训练:相比无计划 > 5x;GPU 利用率 > 90%
· 顺序聚合带宽随 DSS 节点线性扩展
工作量:约 3.5 个月。
Phase 8 — 生产就绪 (M8 / GA) [Track D]
交付:
· 可观测性:MDS/ChunkStore/客户端 的指标、追踪、仪表板
· IAM/策略集成;静态加密(复用);审计
· 运维工具:集群引导、节点生命周期、KV 备份/恢复
· Kubernetes CSI 驱动(RWX FUSE,RWO 块)
· 浸泡(30 天)+ 混沌 + Jepsen 式一致性测试 全绿
· 文档(管理、API、调优)——双语
M8 验收:通过生产就绪评审;满足 GA 标准。
工作量:约 3 个月(与 Phase 7 重叠)。
5. 里程碑时间线(粗略,约 8–10 人团队)
季度 在研里程碑 可用产出
──────── ───────────────────────────────────────── ────────────────────────
Q1 M0 冻结;M1 元数据内核;M2 启动 —
Q2 M2 chunk 完成;M3 FUSE MVP ★ POSIX 可用(fseek/fread)
Q3 M4 S3;M5 块启动 文件 + 对象统一
Q4 M5 块完成;M6 HA 块 + 集群 HA
Q5 M7 性能 达到 AI 性能目标
Q6 M8 生产就绪 GA
到 POSIX MVP 的关键路径: M0 → M1 → M2 → M3 ≈ 7–9 个月
到 GA 的关键路径: ≈ 18–24 个月
并行:M0 后 Track A 与 B 并行;Track C(FUSE)在 Phase 2 中期对接(先 mock 后真实 API)启动;Track D 测试从 M1 起运行。
6. 依赖图(构建顺序）
┌── rustfs-kv ──┐
M0 ──────┤ ├── rustfs-mds ──┐
└── rustfs-inode┘ │
│ ├── rustfs-client ── rustfs-fuse (M3)
rustfs-placement(共享)──────────┤ ├── s3-frontend (M4)
│ └── block-frontend (M5)
┌── chunk-format ──┐ │
M0 ──────┤ ├── chunk-store ──┘
└── disk-io ───────┘ (复用 RS/bitrot/heal)
│
rustfs-rdma ─────────────────────┴── 性能 (M7)
TiKV 后端 ──────────────────────────── HA (M6)
7. 测试与验证策略
层级 内容 时机
───────────── ───────────────────────────────────────── ──────────────
单元 逐 crate 逻辑、编解码、事务 各阶段,CI 门禁
集成 MDS + ChunkStore + 客户端 端到端 从 M2 起
一致性套件 POSIX(pjdfstest)、S3(s3-tests)、 M3 / M4 / M5
块(fio、libiscsi/SCSI 合规)
混沌 杀 MDS、杀 chunk 节点、分区、 从 M2;M6 门禁
写中途崩溃(PEND/GC 正确性)
一致性 对 KV 事务 + rename/create 做 Jepsen 式 M1 + M6
性能 fio(IOPS/延迟)、IOR/mdtest(并行)、 M3 基线;M7 目标
真实 GPU 训练(利用率)
浸泡 30 天连续负载 + 故障注入 M8
回归 每次合并的 CI 性能 + 正确性门禁 持续
8. 风险登记
风险 缓解
──────────────────────────────────── ──────────────────────────────────────────
FUSE 开销限制 POSIX 吞吐 FUSE-over-io_uring(M7);后续原生客户端;
M3 早期度量
io_uring 内核版本碎片化 trait 抽象的 disk-io + tokio::fs 兜底;
特性探测
商用集群无 RDMA 传输协商 → io_uring TCP
KV(元数据)成为瓶颈 基于 version 的客户端缓存;数据本体**绝不**
入 KV(打包,见 M2);TiKV 分片;M1/M6 基准
亿万级小文件(AI 数据集、node_modules、 打包进大容器(M2);KV 只存元数据 + Slice
pip/conda、临时构建) 指针;客户端写批量化;inline 上限仅给 ≤~1KB;
压实 GC 按高churn(临时/依赖树)定容量
公式放置 vs 再平衡 集群映射 epoch + HRW(最小迁移);
copy-then-switch 在线再平衡(M6)
数据与 KV 提交之间的崩溃窗口 PEND 写意图 + GC 巡查器;M2/M3 混沌验证
chunk on-disk 格式错误代价高 M0 冻结格式 + 黄金向量;格式头带版本以备将来
ChunkStore 全新构建范围蔓延 严格把 RS/bitrot/磁盘/heal 作为库复用;
外壳保持薄(M2 范围守门)
EC 部分写放大(块) 策略路由:块/随机写用副本;写一次数据集用 EC
打包压实在大量删除/临时文件churn下滞后 压实器吞吐按 churn 定容;按容器 dead_bytes
阈值触发;相对客户端 I/O 限速(类同再平衡)
9. 完成定义(逐里程碑）
M0 规范冻结,骨架 CI 全绿,Q1–Q6 已记录
M1 元数据操作在内嵌 KV 上正确 + 原子 + 崩溃安全
M2 chunk 读写逐字节一致、自校验、损坏可 heal、公式一致;小文件打包
(打包/读取/压实)可用;验证 KV 仅存元数据
M3 POSIX 挂载以目标 IOPS/延迟服务 fseek/fread 负载
M4 S3 一致性 + 文件/对象双向可见 + O(1) 列举
M5 虚机从块卷引导;快照/克隆/扩容正确
M6 MDS 故障转移 + 在线再平衡 + 元数据线性扩展
M7 AI 性能目标达成(RDMA 延迟、IOPS、计划乱序吞吐)
M8 可观测性 + CSI + 浸泡/混沌/一致性全绿;通过 PRR → GA
10. 团队结构(建议,约 8–10 人）
2 元数据(Track A):KV 抽象、MDS、placement
2 数据(Track B):chunk-format、chunk-store、packing、disk-io/io_uring
2–3 客户端(Track C):FUSE、S3、块 前端
1–2 平台(Track D):RDMA、可观测性、HA、CSI
1 测试/性能工程(测试台、一致性、混沌、基准)——从第一天起
1 技术负责人 / 架构师(负责规范、跨 track API、设计冻结)
11. 首批行动(未来 2 周）
1. 冻结 on-disk chunk 格式(Q3):编写 chunk-format 规范 + 黄金向量。
2. 锁定 protobuf 线协议契约(MDS + ChunkStore + GetClusterMap)。
3. 决策 KV:在 TransactionalKv 后立起内嵌 redb/RocksDB;预研 TiKV。
4. 立起单仓 crate 骨架 + CI + 测试台外壳。
5. 预研 rustfs-placement(HRW + 集群映射),用单元测试证明 客户端/MDS 一致——
它支撑整个"公式"论点,必须尽早钉死。
12. 小结
一套全新、单模型的统一存储:事务型 KV 之上的无状态 MDS(只存元数据,绝不存数据
本体)、纯公式布局、客户端直连数据面、复用经验证 RS/bitrot/磁盘/heal 的薄 chunk
存储,以及面向 AI 数据集与代码/依赖树中亿万级小文件的一等小文件打包。跨 4 条并行
track、8 个里程碑构建;POSIX MVP 约 7–9 个月,GA 约 18–24 个月。无迁移、无共存、
无遗留格式——永远。
英文镜像:rustfs-dev-plan-EN.md。执行权威设计 RUSTFS-MD-DESIGN-005, 辅以 FEAT-001、LLD-001、LLD-002。