点击上方👆蓝字关注我们！
在 上篇 中，我们对 3FS 各个组件的实现原理进行了详细分析。这些分析给我们留下一个初步的印象： 3FS 团队的目标并不是要研发一个可以在方方面面达到业界一流水平的全能型产品，更多的是在追求一个限定场景下的最优解，这个限定场景就是 DeepSeek 自己的大模型训推场景 。
在这篇文章里，我们从 AI 场景和其他场景中提炼出一些有代表性的典型 case，在元数据面和数据面两个维度上，对 3FS 和业界典型方案进行实测对比，尽可能给读者呈现相对客观的测试结果和对比分析。基于这些测试和分析结果，我们总结出 3FS 带给存储相关领域从业者的启示，并引申出我们对自己产品未来发展方向的思考。
对比分析
AI 场景主流方案
在 AI 场景下，业务流程经历多个阶段将原始数据逐步转化为 AI 所需的：
- 数据收集阶段 ：依据业务诉求借助采样、爬取等工具完成数据采集，并针对特定规则将无效或异常数据清洗掉形成训练所需的原始数据，此阶段输入和输出数据特征为海量、非结构化数据；
- 数据预处理阶段 ：借助大数据处理套件等工具链，针对原始数据进行相应的打标、分类等操作生成训练所需的基础数据，此阶段输入和输出数据特征为海量、非结构化、大小文件混合数据；
- 训练阶段 ：将文本、图片等数据经过分词或识别后，转换为神经网络可识别的数字符号序列，经过单机或多机的并行训练最终生成模型向量数据，此阶段输入数据特征为海量、非结构化、大小文件混合数据，输出是一批模型文件；
- 推理阶段 ：基于训练出的模型文件，经过单机或多机推理生成新的内容，此阶段输入为模型文件和用户请求，输出为大模型推理出的结果。
经过对国内大模型方案调研后发现，除了个别公司选择在专用 IDC 中筹建基础设施，大多数公司会选择公有云弹性的存算资源。从国内外公有云厂商在 AI 场景提供的存储方案来看，对象存储主要用来解决数据收集和预处理中海量文件的存储诉求，文件存储主要用来解决训练和推理阶段高性能并发处理的诉求，两者相互配合作为大模型的存储底座。对比大模型厂商使用的存储方案，文件存储产品主要走以下三种技术路线：
- 自研分布式文件存储 ：厂商使用纯自研或基于开源软件改造的文件存储产品支持内部的训推工作，比如 Meta 自研的 Tectonic 文件系统、DeepSeek 自研的 3FS 文件系统、一些公司采用 HDFS 和 Ceph 改造实现的自研存储系统等，并借助内部丰富的工具集实现存储系统与业务系统的生态融合；
- 并行文件存储 ：厂商直接使用公有云中成熟的并行文件存储产品进行训练和推理工作，比如火山引擎 vePFS、阿里 CPFS、AWS FSx for Lustre、腾讯 CFS Turbo 等，借助数据流动模块打通并行文件存储到对象存储之间的数据流动工作；
- 文件缓存加速层 ：厂商在虚拟机自建 JuiceFS、Alluxio 或直接使用公有云类似产品，比如火山引擎 CloudFS、百度 RapidFS、腾讯 GooseFS 等，文件存储缓存层提供高速访问诉求，借助缓存映射解决文件存储和对象存储间数据流动的诉求。
针对上述总结，3FS 可以作为自研分布式文件系统的典型代表。为了更好的了解其能力，我们选择火山引擎上另外两种技术路线的代表产品来做一番对比，分别是 vePFS 和 CloudFS 。接下来的章节将简单介绍一下这两个产品的架构设计，然后针对元数据面和数据面设计 case 进行场景化对比测试。
对比的系统架构介绍
vePFS
客户端使用私有协议实现：
- 架构和 FUSE 类似，采用内核态和用户态协作的方式。内核部分负责对接 VFS 框架实现标准的 POSIX 接口，用户态部分负责和后端的元数据服务、存储服务进行交互。内核态和用户态之间通过共享内存解决通信问题；
- 基于分布式锁保证了多客户端之间的数据一致性，在此基础上客户端充分利用各类元数据和数据缓存加速读场景下的并发效率。
元数据服务采用分布式对称架构设计：
- 存储节点和元数据节点是一体的，每个存储节点同时也是元数据节点；
- 由客户端节点和元数据节点共同维护文件系统的元数据信息，前者承载文件的元数据更新入口，后者处理元数据读写请求并维护文件打开的状态；
- 目录树采用 Hash 结构组织，分布在不同的元数据节点中，当 Hash 桶满了后自动进行分裂；
- 支持 Fileset，可以在系统中划分出独立的元数据空间，拥有独立的 inode 空间和管理能力。这个能力可以让用户更加精细地管理不同业务。
存储服务负责处理用户的读写 IO 请求：
- 支持副本和 EC 两种模式；
- 文件进行分块存储，并针对写入的 IO 大小采用不同的处理策略。大 IO 会新分配一个完整的 chunk 来存放写入的数据，然后修改上层映射信息。小 IO 写入的数据则先保存到 WAL 中，日志落盘成功后即返回给上层，后台尽力对 IO 进行合并，最终将数据下刷到 chunk 中；
- 与 3FS 类似，在使用 RDMA 进行通信时，支持单边交互方式。
火山引擎在产品上进一步集成了一系列企业级能力，如下图所示：
- vePFS 产品的性能随容量线性增长。借助 RDMA 协议最高可支持 TiB/s 级吞吐带宽、千万级 IOPS 、亚毫秒时延的性能指标。同时支持 TCP 协议访问，灵活适配多种接入方式；
- 支持数据洞察能力，辅助用户有效挖掘数据热点，提升热数据的核心价值；
- 借助丰富的数据流动策略实现与对象存储之间的双向同步，降低存储成本；
- 在数据安全上，支持面向资源管理维度和文件访问维度的审计日志，并支持 IAM 子用户的目录级访问权限控制；
- 支持基于 Fileset 目录级配额管理和 QoS 控制，有效隔离资源访问；
- 在服务稳定性上，采用多级可靠性架构设计，保障文件系统高效稳定运行。
- 与火山引擎机器学习平台 MLP、容器服务 VKE 深度集成，提供完整训练推理能力。
CloudFS
客户端支持通过 FUSE Client 或 SDK 接入，分别对应到 3FS 的 FUSE Client 和 USRBIO 两种方式。
元数据服务（aka DanceNN）采用 Federation 架构，通过动态子树拆分技术，实现了元数据集群的水平扩展能力：
- 系统对外呈现统一的命名空间视图，内部由多组 DanceNN 组成。每组 DanceNN 负责管理目录树的一部分，通过主从架构实现高可用；
- 每个 DanceNN 节点的通过本地 KV 引擎存储目录树 Dentry、Inode、Block 位置等信息；
- 当某组 DanceNN 的容量或 IOPS 达到瓶颈时，通过子树拆分技术把其负责的一部分路径迁移到其它的 DanceNN 组上。
存储服务由近计算分布式读写缓存和数据湖组成：
- 近计算缓存：
- 既可以独立部署，也支持和 GPU 节点混部，利用 GPU集群的空闲内存和本地盘资源构建缓存资源池；
- 写缓存的复制协议支持链式复制和星型复制两种模式。链式复制和社区 HDFS 一致，大 IO 场景能实现更高的吞吐。星型复制由主节点将数据并行写到多个从节点，小 IO 场景能实现更低的延时；
- 单机引擎针对大小文件实现了不同的引擎。大文件切成多个 Chunk File 独立存储，而小文件则通过把多个文件存储到一个 Chunk File 的方式来解决 LOSF (Lots of Small Files) 的问题；
- 整个 IO 路径针对 RDMA、NVMe SSD 做了深度优化，支持 polling 和 event-driven 两种 IO 模型，允许业务在极致性能和资源消耗之间做权衡。
- 数据湖：支持对接不同形态的数据湖生态，包括字节内部的 HDFS、火山引擎 TOS，以及Azure Blob、GCS 等第三方云对象存储。
火山引擎在产品上进一步集成了一系列企业级能力，如下图所示：
- 支持写缓存，GPU 训练过程中产生的周期性 checkpoint 可以先写入到 CloudFS 做写加速；再配合多种不同的生命周期规则，异步沉降到远端的存储。当前支持的生命周期规则包括：
- 数据块粒度支持 LRU/ARC 策略；
- 文件/目录粒度支持 mtime/访问频度策略。
- 支持读缓存，checkpoint 以及 dataset 数据在读的时候，提前预热到 CloudFS 中做读访问加速；
- 支持透明加速的能力，原始的目录结构和数据格式可以“零”代码修改透出。
和 3FS 架构的对比
vePFS、CloudFS、3FS 在三个主要组件客户端、元数据服务、存储服务上，对架构差别进行了简单对比总结：
- 客户端 ：
- vePFS 的私有协议客户端，采用内核态和用户态协同设计的方案，这一点和 CloudFS、3FS 的 FUSE Client 实现原理类似；
- CloudFS 和 3FS 还支持 SDK 供业务适配接入，可提供比各自 FUSE Client 更好的性能。CloudFS SDK 是全功能的，完全独立于 FUSE 客户端工作。3FS USRBIO 则只实现了读写操作，需要配合 FUSE Client 一起使用。
- 元数据服务 ：
- vePFS 采用目录随机打散的经典设计，类似的设计思路被 Lustre DNE、BeeGFS、WekaFS 等系统广泛采用。在这个设计中，整个目录树按照目录打散到所有元数据节点上，每个元数据节点负责一部分目录。跨节点操作的正确性通过分布式锁保证；
- CloudFS 采用子树划分的经典设计，类似的设计思路被 HDFS、CephFS、JuiceFS 企业版等系统广泛采用。在这个设计中，整个目录树按照子树切分到所有元数据节点上，每个元数据节点负责一部分子树。跨节点操作要么不支持，要么通过分布式锁保证正确性；
- 3FS 采用元数据服务存算分离的经典设计，类似的设计思路被 Tectonic、ADSL、HopsFS 等系统广泛采用。在这个设计中，整个目录树的数据被抽象成一条条 KV 键值对或数据库记录，持久化到底层分布式 KV 或数据库中，上层由一层元数据服务层实现文件系统语义。跨节点操作的正确性通过分布式事务保证。
- 存储服务 ：
- vePFS 支持副本和 EC 两种存储模式。这两种存储模式是业界最主流的方案，通常副本模式性能更高，EC 模式得盘率更高；
- CloudFS 采用数据湖 + 近计算缓存的存储模式，类似的方案被 JuiceFS、Alluxio 等系统广泛采用。在这种设计中，数据湖提供低成本存储空间存储全量数据，近计算缓存部分负责加速热点数据的读写性能；
- 3FS 目前仅支持副本存储模式，代码中预留了 EC 的选项尚未实现。
测试环境配置
3FS、vePFS、CloudFS 的服务端在部署时均采用以下服务器配置（以下简称服务器 A）：
具体部署形式如下：
为了更公平地进行对比测试，vePFS 在测试过程中采用和 3FS、CloudFS 一样的三副本配置。火山引擎上默认提供的 vePFS 采用 EC 配置，如果有三副本需求，可以工单联系火山引擎服务支持团队。
针对元数据和数据面我们整体设计和测试了 29 个用例，限于篇幅原因，本文只呈现了 9 个关键的测试用例和结果分析。
元数据面测试和分析
技术点分析对比
在进行测试之前，我们先从技术架构对 vePFS、CloudFS、3FS 的元数据面进行关键技术点分析。
请求通路
- vePFS 和 CloudFS 在文件系统层，分别基于目录和子树做元数据分布式化，并解决一致性、可靠性等问题，系统设计会更复杂；
- 3FS 则将分布式能力下沉到底层 KV 存储，并利用 FoundationDB serializable 的强 ACID 事务语义，简化了元数据整体设计，及目录语义实现。但该架构很难做到极致性能，存在系统请求通路较长、事务冲突场景下性能恶化等问题。
POSIX 语义
- vePFS 较完整支持了 POSIX 语义，支持私有客户端、NFS、SMB 等接入协议；
- CloudFS 未完全支持 POSIX 语义，支持 FUSE 和 SDK；
- 3FS 未完全支持 POSIX 语义，支持 FUSE 和 USRBIO。
增值特性
- vePFS 支持完善的增值特性，包括文件锁、Fileset 级别的配额、QoS、快照等，使其有更广的应用场景。比如，目录配额对很多企业用户来说是强需；
- CloudFS 支持多介质、容量 QoS、多级元数据缓存能力、近计算端部署等，面向多租户、分级存储方面比较有优势；
- 3FS 无增值特性支持。
场景化分析和测试
以典型 AI 训练场景的元数据行为作为输入，对 vePFS、CloudFS、3FS 三种存储，进行了对比测试，覆盖以下场景化测试：
- 场景一 ：多模态训练场景准备数据集阶段，会并发向文件系统写入海量小文件，数据集一般包含数百万到数十亿个样本数据，文件大小在 KiB～MiB 级，要求存储有很高的小文件创建写吞吐。针对该场景下对文件系统元数据能力要求，设计 测试用例 1：小文件创建删除测试 ；
- 场景二 ：多模态训练场景模型训练阶段，会加载清洗后的数据集，并发从存储系统读取海量小文件，算力集群可达千卡以上规模，数据规模较清洗前小一个数量级，但要求存储有很高的小文件读吞吐。该场景下对文件系统元数据读能力有一定要求，设计 测试用例 2：小文件并发读测试 ；
- 场景三 ：扩展到文件系统通用场景，典型如 HPC 场景，涉及基因、气象等行业，业务需求更多样复杂：重性能、重语义完整性，依赖一致性缓存、增值特性、丰富的接入协议等，对系统能力的全面性有更高要求。受限于时间及测试资源，针对通用场景，我们选取 POSIX 语义完整性做验证，设计 测试用例 3：POSIX 兼容性测试 。
测试用例 1：小文件创建删除测试
用例 ：多客户端 mdtest 分别在独立目录下并发创建、删除小文件，每目录下创建 100w 文件。
测试结果 ：以下数据为单个元数据节点的性能
结果分析 ：
- CloudFS 创建文件性能和 vePFS 相差较大的原因是创建文件整体链路较长，需要通过 Proxy 到 NameNode 再做高可用复制；
- 3FS 元数据写性能与 vePFS 相差较大的原因是基于通用分布式 KV 系统构建，整体链路较长，事务开销大。
测试用例 2：小文件并发读测试
用例 ：多客户端 mdtest 分别在独立目录下并发读文件，每目录下有 100w 文件。
测试结果 ：以下数据为单个元数据节点的性能
结果分析：
- CloudFS 由于提供的是全路径的参数形式，和 vePFS、3FS 按 inode 分级解析的方式相比，一个请求的路径解析步骤较多，拖慢了整体的执行效率；
- 3FS 较 vePFS 差距较大，依然是整体架构通路较长、请求多跳，以及事务开销等原因导致。
测试用例 3：POSIX 兼容性测试
用例 ：使用通用 POSIX 接口兼容性测试套件 pjdfstest，执行全量测试用例，并比较各产品用例通过率。
测试结果 ：
结果分 析 ：
- vePFS 失败用例较少，仅部分场景 case 失败，POSIX 语义支持较完整；
- CloudFS 和 3FS 相对不那么完善，两者不支持管道文件、块设备文件、字符设备文件、套接字文件等文件类型，相关文件类型的测试case全部失败。这些语义不是 AI 训推场景的强需，CloudFS 和 3FS 在当前的通过率下也能很好的服务这些场景。
结论
基于以上技术架构对比分析，结合测试验证，可以看到：
- 架构层面 ，3FS 很好践行了系统分层思想，借助分布式 KV 存储能力，简化自身架构设计，及目录语义实现。该架构也导致元数据通路请求放大，很难做到极致性能；
- 语义特性上 ，3FS 舍弃了部分 POSIX 语义支持及对通用文件系统增值特性的完善。
整体上，3FS 元数据的设计对小文件不够友好，CloudFS 当前也有类似的问题。对于这两种系统，可以由上层通过 FFRecord 之类的打包格式做小文件合并，将元数据性能问题转化成数据面的 IO 性能问题。
数据面测试和分析
技术点分析对比
在进行对比测试之前，我们先从技术架构对 vePFS、CloudFS、3FS 的数据面进行关键技术点分析。
客户端
- vePFS 使用私有协议客户端，在客户端中实现了 IO 异步化、RPC 合并、缓存与预取、用户态和内核态共享内存等优化手段；
- CloudFS 提供 FUSE Client 和 SDK 两种接入方式，SDK 在数据缓存、并发消息通信、零拷贝方向做了深度性能优化；
- 3FS 提供 FUSE Client 和 USRBIO 两种接入方式，USRBIO 采用全用户态、异步、零拷贝、共享内存的方式，相比 FUSE Client 能够提供更极致的端侧接入性能。
读写路由
- 常见的读写路由模式包括主路由模式和星型路由模式两种：
- 主路由模式：由 Client 先把数据发往存储主节点，再由存储主节点再转发到其他节点；
- 星型路由模式：Client 直接把数据分发到存储节点分片上。
- vePFS 以多副本存储数据时采用星型路由模式，以 EC 存储数据时采用主路由模式；
- CloudFS 同时支持主路由模式和星型路由模式；
- 3FS 采用链式复制主路由模式，采用多副本方式，从链首开始写，传播到链尾；
- vePFS、CloudFS、3FS 都可支持任意副本读。
冗余度&网络放大
- 副本模式：假设配置为三副本
- 写场景：3FS 采用主路由模式，计算节点只出一份写数据对应放大为 1 倍，而 vePFS 和 CloudFS 星型路由模式，计算节点网络出放大为 3 倍，由此看 3FS 计算节点放大更优于 vePFS 和 CloudFS，但 3FS 在存储节点上由于副本间链式复制，会额外多出2倍存储网络出放大；
- 读场景：3FS、vePFS、CloudFS 都是从客户端向后端存储节点读，计算节点和存储节点的网络放大都是一致的。
- EC 模式：3FS 和 CloudFS 不支持 EC 模式。假设 vePFS 的 EC 配置为 8+2，写场景采用主路由模式，主节点网络出放大为 1.25 倍，相比副本模式，EC模式在整体网络出放大上得到了很大改善。但 EC 同样也带来一定的弊端，比如EC编解码会带来 CPU 开销，数据 EC 切片也会涉及到额外的数据拷贝开销。
空间管理
- vePFS 采用定长的 chunk 管理，比如 2MiB 配置，不同文件可对 chunk 复用，文件删除需要进行碎片整理或者GC操作，软件实现较复杂；
- CloudFS 支持变长的 chunk 管理，用于节点故障或者慢节点等场景下快速的切 chunk，降低吞吐和延时的抖动问题。在 chunk 的持久化管理方面，大文件每个 chunk 独立存放，较好的解决了文件删除后的数据高效回收；小文件则采用聚合到大文件的方式，解决了海量小文件的问题；
- 3FS chunk大小范围 64KiB-64MiB，按照 2 的幂次递增，共 11 种，Allocator 以用户设置的最大chunksize进行自适应，按照最大chunksize进行切分后，选择最接近实际空间大小的物理块进行分配，不同文件不可对 chunk 复用，文件删除对应 chunk 即可进行回收，软件实现简单。
场景化分析和测试
我们以大模型训推场景下的 IO Pattern 作为输入，对 vePFS、CloudFS、3FS 三种存储，在冗余度都配置成三副本的情况下，进行了对比测试，覆盖以下场景化测试：
- 场景 1 ：在模型数据集收集场景中，会收集大量数据集用于训练，这些训练数据来源不同地域及不同领域，收集完成后会采用多文件多并发方式写入存储，因此我们构建数据收集场景，采用多客户端多文件并行以 IO 大小 1MiB 进行文件写入，测试后端存储写能力，详见 测试用例 4：存储节点写吞吐测试 ；
- 场景 2 ：在大模型的训练过程中，需要成千上万张卡进行并行分布式训练，机器数量众多，故障率也随之升高，为了确保训练任务能够在故障后恢复，训练过程中必须定期保存 CheckPoint，CheckPoint 采用多文件多并发、大吞吐的方式写入后端存储，因此我们采用单客户端多文件多并发以 IO 大小 4MiB写入文件，测试单客户端写能力，详见 测试用例5：单客户端写吞吐测试 ；
- 场景 3 ：在模型分发场景中，多个客户端会并行从后端存储拉取模型，后端存储的带宽能力直接决定多客户端模型拉取的时长，因此我们采用多客户端并行以 IO 大小 1MiB 读取文件，测试后端存储读能力，详见 测试用例 6：存储节点读吞吐测试 ；
- 场景 4 ：在推理场景中，单客户端读取能力也显得尤为重要，直接影响单个客户拉取模型时长，因此我们采用单客户端多文件多并发以 IO 大小 4MiB读取文件，测试单客户端读能力，详见 测试用例7：单客户端读吞吐测试 ；
- 场景5 ：其它场景，除去训推场景对后端存储读写之外，存储空间占用放大以及硬盘读写放大也是衡量存储系统重要的指标，存储空间放大直接影响存储空间利用率 ，硬盘读写放大影响了硬盘的有效利用率，进而影响集群的带宽性能。因此在 测试用例 8 中我们覆盖了空间占用放大的测试 ，在 测试用例 9 中我们覆盖了修改写对硬盘读写放大的测试 。
测试用例 4：存储节点写吞吐测试
用例 ：构建 9 个目录，每个目录下 90000 个文件，每个文件大小 2MiB，每个 IO 大小 1MiB 追加写入，多个客户端同时下发写请求，存储配置为三副本。
测试结果 ：以下数据均为单节点提供给客户端的能力
结果分析 ：vePFS、CloudFS 都是采用星型模式写入，性能更极致，单节点的性能较高。3FS 采用主路由模式各个副本间链式串行写入，存储侧多出 2 倍的串行写入时延，在同等并发情况下，实测过程中存储节点收到的压力较低，且 CPU 很闲，系统写吞吐无法压上去，没有充分发挥后端存储性能，该数值并不代表 3FS 存储节点写吞吐上限低。
测试用例 5：单客户端写吞吐测试
用例 ：单客户端，构建10000 个文件，文件大小500MiB，多文件多并发写，每个 IO 大小为 4MiB，存储配置为三副本。
测试结果 ：
结果分析 ：从数据结果上看 vePFS 和 CloudFS 单客户端写能力能够达到较高水平。实测 3FS 单客户端写吞吐较低，即使加大并发和调参，也无法提升单客户端写吞吐能力，此数据理论上仍有调优空间，欢迎大家交流和指正。
测试用例 6：存储节点读吞吐测试
用例 ：构建1个目录，该目录下文件 200 个，每个文件 100GiB，采用 1MiB 进行数据预埋，预埋完成后，按照 1MiB 进行顺序读，多个客户端下发相同的并发请求，存储采用三副本配置。
测试结 果 ：以下数据均为单节点提供给客户端的能力
结果分析 ：一开始 3FS 单个节点的平均读能力数据为 33.67 GiB/s，通过更换 CPU、内存配置更好的存储机型，同时采用绑核、调参等优化手段，单个节点的平均读能力最终优化到 38 GiB/s，与官方宣称的性能接近，但整体看 3FS 相比 CloudFS 和 vePFS 读带宽能力略低。
测试用例 7：单客户端读吞吐测试
用例 ：单客户端，构建 2000 个文件，文件大小 500MiB，多文件多并发读，每个 IO 大小为 4MiB，存储配置为三副本。
测试结果 ：
结果分析 ：由于 CloudFS SDK 在端侧做了大量的读性能优化，体现出了较好的单机读吞吐能力。而 vePFS 受限 CRC 开销、跨 NUMA 访存等原因导致 CPU 达到瓶颈，同理 3FS USRBIO 同样也受限 CPU 瓶颈，二者能力基本持平。
测试用例 8：空间占用放大测试
3FS 配置 1MiB chunksize， Chunk Engine 按照写入数据大小进行 1MiB 内自适应分配，如果写入数据超过 1MiB，则再分配新 chunk，依次类推直到存储完整个文件数据。本章节通过不同数据 Pattern，测试数据对齐和非对齐场景下的空间占用放大。
用例 ：
- Pattern1 File Size 128KiB：单目录下配置 100000 个文件，每个文件大小 128KiB，预埋 IO 大小写入 128KiB，存储配置为三副本；
- Pattern2 File Size 128KiB+4KiB：单目录下配置 100000 个文件，每个文件大小128KiB+4KiB，预埋 IO 大小写入 128KiB+4KiB，存储配置为三副本；
- Pattern3 File Size 1MiB+8KiB：单目录下配置 100000 个文件，每个文件大小 1MiB+8KiB，预埋 IO 大小写入 1MiB+8KiB，存储配置为三副本。
测试结果 ：
结果分析 ：
- 在 Pattern1 场景下，三种产品的放大都是接近的；
- 在 Pattern2 场景下，小文件 128KiB+4KiB 非 chunksize 对齐写得情况下，除去三副本放大外，3FS 按照 64KiB 的 2 的幂次方扩展 chunksize 扩展，chunk 空间也会放大 1 倍，空间最大浪费可以接近到 6 倍；
- 在 Pattern3 场景下，小文件 1MiB+8Kib，3FS 会占用 1MiB chunk 和 64KiB 的 chunk，空间放大到 3.1；vePFS 的 chunk 大小为 2MiB，此 Pattern 下文件占用 chunk 空间超 1/2，剩余 chunk 空间会作为碎片损耗造成放大，如果后续遇到比剩余 chunk 空间小的文件写入，碎片空间依旧可以复用。
测试用例 9：覆盖写产生的硬盘读写放大测试
因为 CloudFS 当前不支持覆盖写，此场景只包括 vePFS 和 3FS 测试。
用例 ：
- Pattern1 128KiB rwrite：单目录下配置 100000 个文件，每个文件大小 10MiB，以 128KiB IO 进行数据预埋，预埋完后采用 128KiB 随机覆盖写；
- Pattern2 128KiB+4KiB rwrite：单目录下配置 100000 个文件，每个文件大小 10MiB，以 128KiB IO 进行数据预埋，预埋完后采用 128KiB+4KiB 随机覆盖写；
- Pattern3 4KiB rwrite：单目录下配置 100000 个文件，每个文件大小 10MiB，以 1MiB IO 进行数据预埋，预埋完后采用 4KiB 随机覆盖写。
测试结果 ：
结果分析 ：
- 3FS 按照 1MiB 进行请求拆分后，对应 Chunk Engine 的 chunksize 最大为 1MiB，因为 3FS 的修改写需要把整 chunk 1MiB 读取，再补齐需要修改的数据，然后再以 1MiB 写入新 chunk。系统配置为三副本，每个分片都会有整个 chunk 的读和整个 chunk 的写：
- 针对 Pattern1 放大理论值：(1MiB 读 + 1MiB 写)÷128KiB*3=48，实测值为 50；
- 针对 Pattern2 放大理论值：(1MiB 读 + 1MiB 写)÷(128KiB+4KiB)*3=46.5，实测值为 48；
- 针对 Pattern3 放大理论值：(1MiB 读 + 1MiB 写)÷(4KiB)*3=1536，实测值为 1500。
- vePFS 没有读放大，只有对应的三副本写产生的放大为 3 左右。
结论
基于以上技术架构对比分析，结合测试验证，可以看到：
- 3FS 采用链式复制，以多副本的方式，多跳串行写入后端存储，牺牲空间利用率和写入时延，换取更好的读性能。在读的时候，3FS 采用一跳任意副本读取，对大块读场景非常友好，能够提供极致的读性能；
- 相比可支持 EC 的文件系统，3FS 采用三副本的方式空间占用高，如果同时遇见小文件写，chunk 之间数据不能共享，更加加剧 chunk 空间浪费；
- 3FS 对小文件覆盖写不友好，需要按照 chunk 粒度“读-改-写”，带来较大的硬盘读写放大。
整体看 3FS 在 DeepSeek 模型分发等封闭生态内做得比较好，拉通场景化应用对系统架构进行了取舍，面向读场景进行优化、简化软件实现复杂度，最终端到端有较好的效果。
3FS 的启示
3FS 贯穿在整个架构设计中理念可以概括为两个关键字： 协同设计 和 权衡取舍 。
协同设计
在计算机体系架构领域， 分层式系统架构设计 被认为是应对复杂性的黄金法则。对于一个复杂的系统，通过合理的层次抽象，将复杂的问题分解为更小更聚焦的问题分而治之，可以极大降低研发人员的心智负担，显著提升研发效率，让整个系统更容易构建出来。
在大规模 AI 训练与推理的工程实践中，分层式系统架构为算法工程师、训练平台工程师、存储工程师等角色划分了清晰的职责边界，让大家专注于各自擅长的领域，有效缩短了业务从设计到落地到规模上量的周期。但是，不同领域间天然存在着认知屏障，这些屏障哪怕是薄成一层纱，不捅破也会形成效率陷阱和协同盲区。处于屏障两边的不同角色间，会因为没有理解到对方领域的最佳实践，致使系统的运转效率达不到最优。这些效率陷阱和协同盲区很可能还是隐形的，没有被注意到。
DeepSeek 团队应该是意识到了这一点，主动打破认知屏障，以 USRBIO 作为桥梁， 拉进 3FS 业务方和 3FS 达成了一致认知：
- 业务方认识到大文件大 IO 才是对 3FS 更友好的访问模式，愿意主动适配，在业务和框架侧做好小文件聚合来充分发挥出 3FS 的吞吐优势；
- 3FS 针对如上场景极致调优端到端性能，同时针对 USRBIO 上手门槛高的问题，提供了 FFRecord 打包格式、DataLoader 等配套基础组件来简化使用复杂度。
通过这种 层次间的协同设计 ，3FS 很好地满足了 DeepSeek 业务所需要的性能。
权衡取舍
DeepSeek 团队大约百人的规模，承担了算法和基础设施的全部预研、开发与维护工作。在这样的人力资源配置下，若要求自研文件系统在大部分技术指标上都达到业界顶尖水平，显然是不现实的，也完全没有必要。3FS 的研发人员清醒地意识到了这一点，在系统设计上处处体现出权衡取舍的艺术，将有限的精力聚焦到几个关键的技术点上，其它部分则不追求极致。
3FS 在系统设计上权衡取舍的点包括：
- 专注优化高吞吐读写负载，其它负载类型下的性能未深度调优：
- USERBIO、链式复制、chunk 整体写等设计，都是对大文件、大 IO 比较友好的设计。但这些设计在小文件小 IO 场景存在一些固有缺陷，例如，链式复制协议会导致延时较高，chunk 整体写会导致较大的空间放大；
- 元数据使用 FoundationDB 存储，未针对事务执行效率进行深度优化，导致元数据性能上限较低。这一点对大文件场景不关键，但是对海量小文件场景不友好。3FS 未打算解决这个问题，而是让上层业务做规避。
- 仅适配 DeepSeek 的基础设施，其它环境的兼容性不是设计目标：
- DeepSeek 内部的环境均采用 RDMA 网络互联，3FS 于是舍弃掉了对非 RDMA 环境的支持；
- SSD 磁盘有 512 字节、4096 字节两种扇区配置，3FS 在代码中只支持 512 字节扇区，导致在 4096 字节扇区的环境运行时很容易出现存储节点崩溃。在我们测试 3FS 过程中，这一点带来了一些困扰。当然，这个问题不难修复，但是从中透露出来的一个信息是，如果想要将 3FS 推广到更多 DeepSeek 外的生产环境，还有一些代码适配和测试工作需要做。
- 系统的稳定性设计较为基础，对于环境稳定性、运维能力要求较高：
- 系统采用了重 Master 的设计模式，Master 一旦故障会影响整个系统的服务。有严格 SLA 承诺的系统应该避免这种设计，采取服务面和控制面分离的做法，避免 Master 故障后因为恢复时间较长打破 SLA；
- 元数据和数据节点仅依赖和 Master 的租约判断节点是否可以服务，没有针对网络分区、网络单工、交换机黑洞等情况做更精细的防御，网络出现抖动时很容易影响到服务质量。当然，类似的网络问题在 DeepSeek 使用的高质量 InfiniBand 网络里可能极少出现，因此 3FS 没有着重考虑。
这些权衡取舍让 3FS 系统看起来不那么完美，短板很短，长板又很长。但是从 DeepSeek 的角度看，一切刚刚好。
未来展望
继续挖掘 3FS 的设计理念，我们发现它的所有做法始终是在回答一个更本质的问题： 一个产品该如何做才能服务好目标客户 。对于 3FS，它最初的目标客户只有 DeepSeek，服务好 DeepSeek 就是这个产品所需要做的一切。
但是对于我们，这个问题的答案是不一样的。和 DeepSeek 高度聚焦的业务场景不同，云文件存储面向各行各业的用户，业务场景复杂多样，既有和 DeepSeek 类似的 AI 训练和推理场景，还有自动驾驶、渲染、金融、办公等场景。这些场景呈现出大文件、小文件、随机 IO、顺序 IO、元数据敏感等截然不同的负载特点。诚然，我们可以为每一种业务场景做一款类似 3FS 的定制系统，但这样我们就需要开发很多不同的系统来覆盖这些场景，既让自己的维护工作量多到爆炸，也让用户在做选择的时候极为痛苦。因此，我们认为，在系统内部做加法封装住所有的复杂度，对客户做减法呈现更简单易用的产品形态，反而是和 3FS 设计理念更契合的做法。
尽管当下 vePFS 和 CloudFS 在训练场景可以实现不输于 3FS 的效果，但是放眼未来，用户的数据规模仍然在快速增长，业务复杂度仍然在不断提高，整个文件领域依然面临很大的挑战，广大的从业者任重道远。从这些挑战里，我们提炼出以下几个最关键的问题：
问题 1：和对象存储之间的双向数据流动问题
对象存储具备极致的弹性、极低的成本、极高的可靠性、完备的生态，是客户在云上进行数据存储的首选，许多业务流程均以对象存储为中心进行驱动。但是对象存储并不能覆盖所有业务场景，文件系统在很多场景下依然是用户的首选：
- 存在大量的软件和框架未完成对象存储原生接口的适配，强依赖文件系统语义；
- 对象存储在海量小文件场景下的元数据和 IO 性能表现，和文件存储相比存在一定差距；
- 部分用户对文件系统的使用方式更熟悉，更倾向于使用文件系统。
如果文件存储能实现和对象存储间的双向数据流动，做到“一处数据，多处呈现，按需流动”，减少用户自己在系统间来回倒腾数据的运维成本，无疑能够大幅提升用户数据处理的效率和体验。这个能力只是实现基础版本并不难，但是要做到产品逻辑智能易用、流转效率极速稳定，对产品设计和架构设计而言是极大的挑战。
问题 2：万亿文件数规模的元数据扩展性问题
在传统的认知里，文件系统的规模一般在千亿，对象存储的规模会达到万亿。数据流动能力的出现打破了这个假设。文件存储的目录在和对象桶建立流动关系后，无法也不可能对对象桶里的对象数进行限制。于是，文件系统的极限规模直接会对齐到对象存储一样的万亿级别。
从千亿文件数规模数扩大十倍到万亿规模，对工程实现的挑战远不是“扩十倍节点进元数据系统”这么简单：
- 节点数增加，意味着发生各类硬件和网络故障的概率大幅增加，对系统的稳定性设计提出了更苛刻的要求；
- 元数据性能需求和文件数规模是相匹配的，十倍文件数规模的提升意味着十倍性能需求的提升。要达到这个目标至少包含两个方面的技术突破：
- 跨节点操作性能的突破。跨节点的正确性无论采用事务还是分布式锁的方案来保证，客观上存在方案原理导致的性能墙，例如，基于事务的方案如果依赖单点时钟节点产生事务时间戳，这个单点就限制了系统的性能在百万 TPS。要打破这种性能墙，就需要在系统架构设计上有原理性的突破；
- 单机引擎性能的突破。平坦的对象存储桶没有目录层级概念，很多用户在使用习惯上会贴近这种设计，容易产生上千万文件甚至上亿文件的巨型目录，巨型目录的主要性能指标要做到和普通目录一致；数据流动能力会在元数据系统产生非常多的后台流量，这些后台流量将消耗一定比例的元数据性能。这些新的变化都要求元数据节点继续挖掘单机引擎性能极限，单机引擎做得越强，在架构设计和产品能力上需要做的妥协就越少。
问题 3：以吞吐衡量的数据面性能和容量弹性解耦问题
容量和性能在传统的云文件存储售卖逻辑里是耦合，一个文件系统能提供多少性能完全是由其容量决定的。
这种售卖模式对于用户来说通常不是性价比最高，在每个阶段用户所需要的性能和容量的比例其实是不一致的。特别是在业务早期，文件系统容量较小，性能是主要矛盾，用户会希望享受到超出其规格（单位容量提供的性能）的性能来加速业务上量。
特别是近期，这种趋势进一步加剧。DeepSeek 的爆火促进了 AI 大模型应用落地，推理需求以惊人的速度增长。在推理部署的场景下，一个文件系统里可能只存了几百 GiB 到数 TiB 的模型文件，但是上百数千个推理服务器同时加载需要 TiB/s 级别吞吐能力才能满足好。
因此，云文件存储在产品上解耦售卖性能和容量将是一个必然趋势。在这个产品能力背后，文件系统的数据面需要一些扎实的工作，确保系统在“平地起高楼”式突发流量的冲击下服务平稳。
问题 4：以业务效果衡量的端侧极致性能问题
作为业务访问的直接入口，客户端的性能直接关系到业务的使用体验。在过去，文件系统通常会采用内核态客户端、SDK、系统调用拦截等客户端实现方案，这些方案或多或少存在使用复杂度高、运维成本高、兼容性差等问题。随着各方面的能力逐步完善，FUSE 成为近年来新兴文件系统的主流客户端方案。
以 FUSE 为基础，端侧的几种优化路线将会呈现出叠加状态，共同服务于性能优化这个核心目标：
- FUSE 工程实现的优化将持续进行，不断触达更高的性能天花板，缩小和其它方案的差距。这是兼容性最好但很有挑战的方案，很多文件系统厂商正在做，也一定会坚持做下去；
- 3FS USRBIO 提供了一个新颖的技术样板，那就是在特定场景下，融合 FUSE 和 SDK 的优势，以 FUSE 保证最普遍的兼容性，以 SDK 提速最关键的 IO 路径。这个思路需要业务配合改造，但是可以预测在 DeepSeek 打样之后将被广泛接受，甚至最终出现行业统一标准。这个标准不一定是 USRBIO，但思路类似；
- 近计算缓存进一步助力客户端的性能。客户端和计算节点位于同一张高速网络，利用计算节点闲置的内存或本地盘资源提供本地或分布式缓存，可以实现热点数据加载的最短路径。
问题 5：海量文件规模下近实时数据分析和洞察问题
随着 AI、大数据等业务的蓬勃发展，用户在文件系统沉淀了海量数据。这些数据的属性和访问行为里蕴含着丰富的价值，经过深入分析和理解后，挖掘出的信息可以帮助用户更全面理解业务负载，从而进一步实施成本、性能、安全等方面的优化。
这类典型的使用场景包括：
- 监控文件的访问频次信息，筛选出低频文件沉降到对象存储，以此降低数据存储的总成本；
- 提供 IO 访问模式、文件大小分布、热点目录等信息帮助业务分析访问瓶颈，指导业务进行小文件打包、热点大目录拆分等优化手段来提升访问性能；
- 支持对文件系统进行多维度统计查询，帮助管理员提高数据管理效率，合理地规划文件系统的资源使用。
文件系统原生支持智能数据分析和洞察能力非常关键，只有原生支持了才可能保证海量文件规模下信息的实时性。在这个基础上，集成大模型的能力也很重要，这是比 SQL 等方式更高效、更自然的用户交互界面。
我们长期思考并致力于解决这些问题，形成的答案正在逐步落地到我们的产品中，并形成一个完备的火山引擎 AI Cloud Native 文件产品体系：
- 对象存储 TOS：作为整个体系的数据湖底座，为其它产品提供稳定可靠的海量数据存储能力。TOS 同时提供平坦桶或分层桶两种选择，用户可以根据自己的实际需求（例如是否需要目录 Rename 能力）进行选择；
- 文件存储 NAS 和 vePFS：提供 POSIX 兼容性完备、高性能的文件存储服务。NAS 作为云原生文件存储，当前更适合通用业务场景，起售容量低，用户按需购买容量和带宽。vePFS 作为实例型产品，更适合有极致性能需求的场景，用户提前规划好容量和性能需求，购买相应的规格；
- 近计算分布式缓存 CloudFS：提供托管和半托管形态的高性能缓存服务。由于和计算节点位于同一张物理网络内，可以借助计算节点的多网卡 RDMA 通信能力，提供极致的访问性能；
- 统一客户端 FSX：为包括 TOS、NAS、vePFS、CloudFS 在内的多款产品提供统一端侧接入能力。FSX 源于 FUSE，在性能和稳定性方面做了诸多改进。同时，FSX 和 IAM 打通支持了细粒度权限管控，并允许把不同系统的挂载点呈现成统一命名空间；
- 数据流动：和 TOS 进行不限地域的双向数据流动，并支持丰富的加载、淘汰、导入、导出策略，是整个体系重点建设的通用能力。基于此能力，用户可以在不同的产品上看到一致的数据，降低了管理和使用数据的心智负担；
- 数据洞察：同样是整个体系重点建设的通用能力。通过支持一些近实时的统计和分析能力，可以让用户更全面理解业务负载，显著提高数据管理效率。
当前，我们的 AI Cloud Native 文件产品体系尚不足以对上述问题交出完美的答卷，但我们满怀信心持续攻坚中，坚信在不远的未来一定可以将这些问题彻底解决掉。敬请期待！
团队招聘
火山引擎文件存储团队 负责字节跳动内部和火山引擎文件存储产品的研发工作，覆盖 vePFS 和 NAS 产品，目前正致力于打造的新一代分布式文件系统，解决超大规模场景下的扩展性、性能、AI native 等问题，打造全球领先的文件存储服务。
团队正在招聘中，base 北京、上海、杭州、成都等地，欢迎感兴趣的同学向我们投递简历！
👉 分布式文件存储产品化开发工程师 ： https://jobs.bytedance.com/experienced/position/7223755133795797309/detail
👉 分布式文件系统研发工程师 ： https://jobs.bytedance.com/experienced/position/6934151347268978952/detail