继 JuiceFS 企业版 v5.3 支撑千亿文件规模之后v5.4 进一步在超大规模场景下提升多项能力。千亿文件规模下单次操作的细小开销也会累积成显著的资源负担元数据分区部署后需要协调不同节点兼顾性能、数据一致性与稳定性。围绕这些问题v5.4 版本包含下面多项新功能和改进百万客户端同时挂载海量文件规模的目录克隆RDMA 带宽利用率超 90%高并发随机读性能提升 100%镜像文件系统支持数据按需同步丰富缓存策略适配更多业务需求多项针对大规模数据的运维管理优化。01 支撑百万客户端接入随着 Agent 走向规模化JuiceFS 团队需要解决一个新的难题在千亿文件的管理负载之上承接百万客户端的连接与并发访问。团队为此进行了持续探索与优化并在企业版 v5.4 中发布这项能力。JuiceFS 采用元数据多分区分布式架构将千亿规模文件的元数据分布到多个 Metadata 节点进行管理。为让这些节点同时承接大规模客户端连接v5.4 将 Metadata 节点与网络代理Proxy合并部署使客户端可以连接到任一 Metadata 节点。接入节点直接处理本分区请求涉及其他分区的请求会内部转发至对应节点。多个客户端会话共用节点间的物理连接减少连接数量及维护开销。除连接复用之外大量客户端会话的查询、状态上报和过期清理也需要控制开销。v5.4 通过索引定位客户端会话减少对无关会话的遍历通过分页查询和采样上报控制状态管理开销对过期会话分批清理避免单轮清理工作过于集中。经过上述优化JuiceFS v5.4 在压测中成功支撑了百万客户端同时接入。原先客户端分别连接多个 Metadata 节点所需连接总数达数千万条。优化后10 个内部 Proxy 节点承接百万条客户端连接并通过连接复用Proxy 到 Metadata Leader 仅需约 400 条后端物理连接大幅降低了 Leader 的连接维护压力。02 快速克隆大型目录用户在为训练数据创建分支或准备测试环境时往往需要一份可独立修改的目录副本当目录规模进一步扩大时克隆本身也会变得更加复杂对于采用多分区架构管理超大规模数据的用户一棵目录树的元数据可能分布在多个 Metadata 分区上克隆需要协调不同节点上的子树复制保持完整的目录层级关系。v5.4 实现了跨分区目录克隆通过递归处理各子树保留原目录树的跨分区布局。克隆只要复制元数据底层对象数据继续共享无需复制对副本的后续写入不会改变源文件的内容。在 30 个 Metadata 分区部署中克隆 1 亿文件耗时 1 分 40 秒平均速度为每秒 100 万个文件。更多分区可以提供更高的并行处理能力实际速度也受 Metadata 负载及目录树跨分区间分布情况影响。需要注意的是跨分区目录克隆没有保证原子性。如果克隆期间源目录有持续的新数据写入新克隆目录中的不同子树可能反映源目录在不同时间点的状态。对一致性有严格要求时需要暂停后再执行克隆。03 性能提升RDMA 高带宽传输利用率超过 90%JuiceFS v5.3 开始支持在客户端与分布式缓存节点之间使用 RDMA降低数据传输的 CPU 开销提高传输效率。v5.4 继续提升带宽利用率、传输稳定性等多方面表现。在客户端配备 400 Gbps RDMA 网卡、分布式缓存节点配备 800 Gbps RDMA 网卡的测试环境中单客户端读取带宽达到 45 GB/s单个分布式缓存节点可提供 90 GB/s 的数据服务带宽网卡利用率达到 90% 以上。提升高并发随机读 IOPS在多进程训练、HPC、渲染等场景中高并发随机读不仅考验存储和网络能力客户端的锁竞争与请求处理开销也可能限制 IOPS 的提升。过去半年JuiceFS 团队通过简化高频处理逻辑、降低锁竞争持续优化高并发随机读性能。优化后随机读 IOPS 较此前整体提升一倍以上使用分布式缓存时单客户端最高达到 18.9 万 IOPS使用本地缓存时单客户端最高达到 15.6 万 IOPS。测试环境双路 AMD 服务器128 核、256 线程配备 1 TB DDR4 内存、100 Gbps 网卡及 3.84 TB NVMe SSD缓存盘内核版本为 Linux 5.14。04 多地域数据访问优化按需同步减少数据复制在多地域、多供应商、多集群的算力场景中部署 JuiceFS 镜像文件系统后镜像端能够自动同步源端的文件和目录。镜像端持续同步元数据跟进目录结构和对象版本变化此前对象数据默认由后台全量同步。但镜像端的业务可能只需要源端的一部分模型、样本或历史目录。例如源端有 10 PB 数据镜像端只访问其中的 1%全量同步就会传输并保存大量业务用不到的数据。v5.4 支持镜像文件系统按需同步对象数据。开启后元数据仍持续同步对象数据不再由后台自动同步。客户端读取时优先从镜像端对象存储获取所需数据如果数据尚未同步则从源端拉取并按需保存在镜像端从而减少不必要的数据传输与存储。如果业务要求首次访问就能获得本地读取性能可以提前预热相关数据需要保留完整数据副本的业务则可继续使用后台同步模式。通过只读节点加速元数据访问对于只需加速元数据访问的业务v5.4 提供了无需创建镜像文件系统的新模式。用户可以在其他区域部署元数据服务节点只读为当地客户端加速元数据读取。客户端仍挂载源文件系统加速节点支持动态扩缩容便于根据访问需求调整部署规模。05 更灵活的缓存管理提升热点缓存命中率一次性扫描的数据通常很少再次使用将这些数据写入缓存可能挤出反复访问的热点数据。默认情况下请求未命中分布式缓存时缓存节点会从对象存储拉取数据并将其写入缓存。v5.4 新增 cache-aside缓存旁路模式开启后未命中的请求改由业务节点直接从对象存储读取不向缓存节点填充此次读取的数据。批量增加缓存节点时保证命中率同时新增多个缓存节点时读取请求可能被分配到尚未缓存所需数据的新节点触发对象存储回源。v5.4 新增 --commission 参数。新节点启用后会保留扩容前的节点映射在自身缓存未命中时向原节点获取数据减少扩容期间的回源请求。减少大容量缓存盘的文件数量使用大容量缓存盘时缓存块逐一保存为独立文件会使缓存盘需要管理的文件数量持续增加。新增的 merge-cache 模式将多个缓存块合并存入大文件并独立保存索引从而大幅减少缓存盘上的文件数量。该功能目前处于 Beta 公测阶段。按字节范围预热文件如果任务只读取大文件中的一部分内容预热整个文件会额外占用缓存空间并产生数据传输。v5.4 支持为预热文件指定一个或多个字节区间只预热与这些区间相交的缓存块使缓存准备范围与任务实际需要读取的内容相匹配。在此功能支持下可以对 lance, parquet 等数据格式进行更精准的预热。06 简化海量文件的运维管理回收站支持按删除时间恢复从回收站恢复文件时用户可能知道误删除发生在哪一段时间却难以仅凭文件名或关键词准确筛选目标。restore 命令新增 start-time 和 end-time 参数在原有关键词过滤之外支持按文件删除时间限定恢复范围。降低 GC / fsck 内存占用检查大规模文件系统时GC / fsck 需要处理大量记录排序过程可能占用大量内存。v5.4 为这两个命令增加外排模式利用磁盘参与排序降低对内存的需求。GC 的外排模式仅允许在 dry-run 下执行用于检查和评估不实际删除数据。通过 Token 白名单限制访问范围v5.4 支持通过 Token 设置白名单白名单可以指定为根目录下的若干一级子目录。使用该 Token 的客户端只能访问和修改这些子目录中的内容从而限定不同团队或任务的数据访问范围。07 小结Scale changes everythingv5.3 将 JuiceFS 带入了一个新的规模阶段。与此同时AI 的发展速度仍在不断刷新我们对数据规模和系统负载的认识。当文件数、客户端数和访问请求量同时进入更高量级后系统所面临的性能、稳定性、一致性和运维复杂度问题不再彼此独立而会相互影响并随着规模扩大进一步放大。v5.4 进一步解决大规模场景下的系统级工程问题覆盖客户端接入、跨分区目录、数据读取、镜像同步与缓存管理。云服务用户现已可以直接在线体验 JuiceFS 企业版 5.4私有部署用户可通过官方渠道获得升级支持。JuiceFS 已广泛应用于 LLM 与多模态大模型、智驾、具身智能、量化金融等领域。我们会继续和这些前沿企业一起持续完善 JuiceFS让基础设施更好地支撑业务发展。