技术支持 广州骏域网站建设专家,怎么做网站的排名优化,男女做污视频在线观看网站,东莞设计网站近期#xff0c;DeepSeek 开源了其文件系统 Fire-Flyer File System (3FS)#xff0c;使得文件系统这一有着 70 多年历时的“古老”的技术#xff0c;又获得了各方的关注。在 AI 业务中#xff0c;企业需要处理大量的文本、图像、视频等非结构化数据#xff0c;还需要应对…近期DeepSeek 开源了其文件系统 Fire-Flyer File System (3FS)使得文件系统这一有着 70 多年历时的“古老”的技术又获得了各方的关注。在 AI 业务中企业需要处理大量的文本、图像、视频等非结构化数据还需要应对数据量的爆炸式增长分布式文件系统因此成为 AI 训练的关键存储技术。
本文旨在通过深入分析 3FS 的实现机制并与 JuiceFS 进行对比以帮助用户理解两种文件系统的区别及其适用场景。同时我们将探讨 3FS 中的值得借鉴的创新技术点。
01 架构对比
3FS
3FS (Fire-Flyer File System) 是一款高性能的分布式文件系统专为解决 AI 训练和推理工作负载而设计该系统使用高性能的 NVMe 和 RDMA 网络提供共享存储层。3FS 由 DeepSeek 在 2025 年 2 月开源。 3FS 主要包括以下模块
集群管理服务Cluster Manager元数据服务Metadata Service存储服务Storage Service客户端 FUSE Client、Native Client 所有模块通过 RDMA 网络通信。元数据服务和存储服务向集群管理服务发送心跳信号。集群管理服务负责处理成员变更并将集群配置分发给其他服务和客户端。为了提高系统的可靠性和避免单点故障会部署多个集群管理服务其中一个被选为主节点。当主节点发生故障时另一个管理器会被提升为主节点。集群配置通常存储在可靠的分布式服务中例如 ZooKeeper 或 etcd。
当进行文件元数据操作例如打开或创建文件/目录请求被发送到元数据服务以实现文件系统语义。元数据服务有多个并且是无状态的它们不直接存储文件元数据而是依赖支持事务的键值数据库 FoundationDB 来存储这些数据。因此客户端可以灵活地连接到任意元数据服务。这种设计使得元数据服务可以在没有状态信息的情况下独立运作进而增强了系统的可伸缩性和可靠性。
每个存储服务管理若干本地 SSD并提供 chunk 存储接口。存储服务采用 CRAQ Chain Replication with Apportioned Queries来确保强一致性。3FS 中存储的文件被拆分为默认 512K 大小相等的块并在多个 SSD 上进行复制从而提高数据的可靠性和访问速度。
3FS 客户端提供两种接入方式 FUSE Client 和 Native Client。 FUSE Client 提供常见 POSIX 接口的支持简单易用。Native Client 提供更高的性能但是用户需要调用客户端 API 具有一定的侵入性下文我们还将对此作更详尽的解析。
JuiceFS
JuiceFS 是一个云原生分布式文件系统其数据存储在对象存储中。社区版可与多种元数据服务集成适用场景广泛于 2021 年在 GitHub 开源。企业版专为高性能场景设计广泛应用于大规模 AI 任务涵盖生成式 AI、自动驾驶、量化金融和生物科技等。 JuiceFS 文件系统包括三部分组成
元数据引擎用于存储文件元数据包括常规文件系统的元数据和文件数据的索引。数据存储一般是对象存储服务可以是公有云的对象存储也可以是私有部署的对象存储服务。JuiceFS 客户端提供 POSIXFUSE、Hadoop SDK、CSI Driver、S3 网关等不同的接入方式。 架构差异
从模块划分上看两个文件系统差异不大都采用了元数据与数据分离的设计各个模块功能也较类似。不同于 3FS 和 JuiceFS 企业版JuiceFS 社区版兼容多种开源数据库存储元数据对元数据的操作都封装在客户端用户不需要再单独运维一个无状态的元数据服务。
存储模块
3FS 使用大量本地 SSD 进行数据存储为了保证数据存储的一致性3FS 使用 CRAQ 这一简洁的数据一致性算法 。几个副本被组成一个 Chain写请求从 Chain 的 Head 开始一直到达 Chain 的 Tail 时返回写成功应答。读请求可以发送到 Chain 的所有副本如果读到脏节点的数据该节点会联系 Tail 节点检查状态。如下图所示。 数据的写入是按顺序逐节点传递因此会带来比较高的延时。如果 Chain 当中的某个副本不可用 3FS 会把这个副本移到 Chain 的末尾等副本可用的时候再做恢复。恢复的时候需要把整个 Chunk 的内容复制到这个副本而非使用不可用期间的增量数据。如果要做到同步写所有副本和增量恢复数据那写的逻辑会复杂非常多比如 Ceph 使用 pg log 保证数据一致性。尽管 3FS 这种设计会导致写延迟但是对于以读为主的 AI 应用场景影响不大。
JuiceFS 利用对象存储作为数据存储解决方案从而可享有对象存储带来的若干优势如数据可靠性、一致性等。存储模块提供了一组用于对象操作的接口包括 GET/PUT/HEAD/LIST 等用户可以根据自己的需求对接具体的存储系统。比如不同云厂商的对象存储也可以选择私有部署的对象存储比如 MinIO、Ceph RADOS 等系统。社区版 JuiceFS 提供本地缓存来应对 AI 场景下的带宽需求JuiceFS 企业版使用分布式缓存满足更大的聚合读带宽的需求。
元数据模块
在 3FS 中文件的属性以 KV 的形式存储在元数据服务中。该服务是一个无状态的高可用服务依靠 FoundationDB 做支撑。FoundationDB 是 Apple 开源的优秀分布式 KV 数据库具有很高的稳定性。FoundationDB 所有键值使用 Key 做全局排序然后均匀拆分到不同的节点上。
为了优化 list 目录的效率3FS 使用字符 “DENT” 前缀加父目录 inode 号和名字作为 dentry 的 Key。Inode 的 Key 是通过将 “INOD” 前缀与 inode ID 连接而构造的其中 inode ID 采用小端字节序编码以便将 inodes 分布到多个 FoundationDB 节点上。这个设计与 JuiceFS 使用的 TKVTransactional Key-Value Database 进行元数据服务的存储方式类似。
JuiceFS 社区版的元数据模块与存储模块类似也提供一组操作元数据的接口可以接入不同的元数据服务比如 RedisTiKV 等 KV 数据库MySQLPostgreSQL 等关系型数据库也可以使用 FoundationDB。JuiceFS 企业版使用自研高性能元数据服务可根据负载情况来平衡数据和热点操作以避免大规模训练中元数据服务热点集中在某些节点的问题比如因为频繁操作临近目录文件的元数据引起。
客户端
3FS 的客户端除了提供 FUSE 操作外还提供了一组 API 用于绕过 FUSE 直接操作数据也就是 Native Client接口的调用方式有点类似于 Linux AIO。这组 API 的作用是避免使用 FUSE 模块带来的数据拷贝从而减少 I/O 延迟和对内存带宽的占用。下面将详细解析这组 API 如何实现用户进程与 FUSE 进程之间的零拷贝通信。
3FS 通过 hf3fs_iov 保存共享内存的大小地址和其他一些属性使用 IoRing 在两个进程间通信。 当用户调用接口创建 hf3fs_iov 时会在 /dev/shm 上分配内存,并创建一个指向这个共享内存的软链接软链接的地址位于 /mount_point/3fs-virt/iovs/,这是个虚拟目录。3FS FUSE 进程收到创建软链接请求并且发现它的地址位于上述虚拟目录后就会根据软链接的名字解析出这块共享内存的相关参数并将内存的地址注册到所有 RDMA 设备除了 IORing 。ibv_reg_mr 返回的结果被存在 RDMABuf::Inner 数据结构中用于后续发送 RDMA 请求。
同时IORing 的内存也使用 hf3fs_iov 保存只是在创建对应的软链接时文件名中会有更多的 IORing 相关的信息。如果 FUSE 进程发现这个内存是用于创建 IORing也会在它的进程内创建对应的 IORing。这样设置之后用户进程和 FUSE 进程就可以访问相同的 IORing 了。
进程间协作方面3FS 在 /mount_point/3fs-virt/iovs/ 目录中创建 3 个不同的虚拟文件用于共享 3 个不同优先级的提交信号量 submit sem 用户进程将请求放到 IORing 后使用这些信号量通知 FUSE 进程有新的请求。 IORing 尾部包含请求完成信号量FUSE 进程通过调用 sem_post 通知用户进程 IORing 上有新的请求完成。以上整个机制确保了两个进程间的高效数据通信和操作同步。
3FS 的 FUSE 客户端实现了文件和目录的基本操作而 JuiceFS FUSE 客户端的实现更加全面。比如在 3FS 文件系统中文件的长度是最终一致的这意味着在写的过程中用户可能访问到不正确的文件长度。而 JuiceFS 在每次成功上传对象后会立即更新文件长度。此外JuiceFS 还提供了以下这些常用的高级文件系统功能
支持 BSD 锁flock和 POSIX 锁fcntl支持 file_copy_range 接口支持 readdirplus 接口支持 fallocate 接口
除了 FUSE 客户端JuiceFS 还提供 Java SDKS3 GatewayCSI Driver 等接入方式。企业版还提供 Python SDKPython SDK 将 JuiceFS 客户端在用户进程中运行避免了通过 FUSE 导致的额外性能开销。具体见文档Python SDK。
02 文件分布对比
3FS 文件分布
3FS 将每个文件分成固定长度的 chunk每个 chunk 位于一个上文提到的链上 CRAQ 算法。用户使用 3FS 提供的一个脚本生成一个 chain table。然后将这个表提交到元数据服务。创建新文件时系统会从表中选取特定数量的 chain 数量由 stripe 定义并将这些 chain 的信息存入文件的元数据中。
因为 3FS 中的 chunk 是固定的客户端只需要获取一次 inode 的 chain 信息就可以根据文件 inode 和 I/O 请求 的 offsetlength 计算出这个请求位于哪些 chunk 上从而避免了每个 I/O 都从数据库查询的需求。可以通过 offset/chunk_size 得到 chunk 的索引。 而 chunk 所在的 chain 的索引就是 chunk_id%stripe。有了 chain 的索引就可以得到 chain 的详细信息比如这个 chain 由哪些 target 组成。然后客户端根据路由信息将 I/O 请求发送到相应的存储服务。存储服务收到写请求后以 copy-on-write COW的方式将数据写入新的位置。原来的数据在引用数据清零前仍然是可读的。
为了应对数据不平衡问题每个文件的第一个 chain 按照轮询 round roubin 的方式选择。比如当 stripe 为 3 时创建一个文件其选择的 chain 为chain0chain1chain2。那么下一个文件的 chain 为chain1chain2 和 chain3。系统会将选择的 3 个 chain 做随机排序然后存储到元数据中。下图为 stripe 为 3 时一个文件的分布示例chain 随机排序后的顺序是132。 JuiceFS 文件分布
JuiceFS 按照 Chunk、Slice、Block 的规则进行数据块管理。每个 Chunk 的大小固定为 64M主要用于优化数据的查找和定位。实际的文件写入操作则在 Slice 上执行每个 Slice 代表一次连续的写入过程属于特定的 Chunk并且不会跨越 Chunk 的边界因此长度不超过 64M。Chunk 和 Slice 主要是逻辑上的划分而 Block默认大小为 4M则是物理存储的基本单位用于在对象存储和磁盘缓存中实现数据的最终存储。更多细节可以参考官网介绍。 JuiceFS 中的 Slice 是在他文件系统中不常见的一个结构。主要功能是记录文件的写入操作并在对象存储中进行持久化。对象存储不支持原地文件修改因此JuiceFS 通过引入 Slice 结构允许更新文件内容而无需重写整个文件。这与 Journal File System 有些类似其中写入操作仅创建新对象而不是覆盖现有对象。修改文件时系统会创建新的 Slice并在该 Slice 上传完毕后更新元数据从而将文件内容指向新的 Slice。被覆盖的 Slice 内容随后通过异步压缩过程从对象存储中删除导致在某些时刻对象存储的使用量会暂时超过文件系统实际使用量。
此外JuiceFS 的所有 Slice 均为一次性写入这减少了对底层对象存储一致性的依赖并大大简化了缓存系统的复杂度使数据一致性更易于保证。这种设计还为实现文件系统的零拷贝语义提供了便利支持如 copy_file_range 和 clone 等操作。
03 3FS RPC (Remote Procedure Call) 框架
3FS 使用 RDMA 作为底层网络通信协议目前 JuiceFS 尚未支持下面对此做一些分析。
3FS 通过实现一个 RPC 框架来完成对底层 IB 网络的操作。除了网络操作外RPC 框架还提供序列化小包合并等能力。因为 C 不具有反射能力所以 3FS 还通过模版实现了一个反射库用于序列化 RPC 使用的 request、response 等数据结构。需要被序列化的数据结构只需要使用特定的宏定义需要序列化的属性。RPC 调用都是异步完成的所以序列化后的数据只能从堆上分配等待调用完成后再释放。为了提高内存的分配和释放速度分配对象都使用了缓存。3FS 的缓存有两部份组成一个 TLS 队列和一个全局队列。 从 TLS 队列获取缓存时不需要加锁当 TLS 缓存为空时就得加锁从全局队列中获取缓存。所以在最优情况下获取缓存是不需要加锁的。
与 I/O 请求的负载不同缓存对象的内存都未注册到 RDMA 设备中。因此当数据到达 IBSocket 后会被拷贝到一个在 IB 设备注册过的缓冲区中。多个 RPC 请求可能被合并为一个 IB 请求发送到对端。下图为 FUSE Client 调用 Meta 服务的 RPC 过程。 04 特性对比
对比项3FSJuiceFS 社区版JuiceFS 企业版元数据无状态元数据服务FoundationDB独立数据库服务自研高性能分布式元数据引擎可横向扩展数据存储自主管理使用对象存储使用对象存储冗余保护多副本对象存储提供对象存储提供数据缓存无缓存本地缓存自研高性能多副本分布式缓存数据加密不支持支持支持数据压缩不支持支持支持配额管理不支持支持支持网络协议RDMATCPTCP快照不支持支持克隆支持克隆POSIX ACL不支持支持支持POSIX 兼容性少量子集完全兼容完全兼容CSI 驱动没有官方支持支持支持客户端FUSE Native ClientPOSIXFUSE、Java SDK、S3 网关POSIXFUSE、Java SDK、S3 网关、Python SDK多云镜像不支持不支持支持跨云和跨区数据复制不支持不支持支持主要维护者DeepSeekJuicedataJuicedata开发语言C, Rust (本地存储引擎)GoGo开源协议MITApache License 2.0商业软件
05 总结
大规模 AI 训练中最主要的需求是高读带宽为此 3FS 采用了性能优先的设计策略将数据存储在高速磁盘上并且用户需要自行管理底层数据存储。这种方法提升了性能但成本较高维护也更繁重。此外为了充分发挥底层硬件的性能其架构实现了客户端到网卡的零拷贝利用共享内存和信号量减少 I/O 延迟和内存带宽占用。此外通过带 TLS 的 I/O buffer pool 和合并网络请求3FS 增强了小 I/O 和文件元数据操作的能力并引入了性能更优的 RDMA 技术。我们将继续关注 3FS 在性能优化方面的进展并探索如何将这些技术应用于我们的场景中。
JuiceFS 使用对象存储作为底层数据存储用户因此可大幅降低存储成本并简化维护工作。为了满足 AI 场景的对读性能的需求JuiceFS 企业版引入了分布式缓存、分布式元数据服务和 Python SDK从而提高文件系统的性能和扩展能力并同时兼顾低存储成本。在接下来发布的 v5.2 企业版中在 TCP 网络中实现了零拷贝进一步提升数据传输效率。
JuiceFS 提供完整的 POSIX 兼容性和成熟活跃的开源生态适应更广泛的使用场景并支持Kubernetes CSI极大简化了云平台的部署和运维工作。此外JuiceFS 还提供了 Quota、安全管理和数据灾备等多项企业级管理功能让企业可以更便捷地在生产环境中部署和应用 JuiceFS。
希望这篇内容能够对你有一些帮助如果有其他疑问欢迎加入 JuiceFS 社区与大家共同交流。
