层实现看S3 Files 使用 Amazon EFSElastic File System作为托管的高性能存储层用来承接需要低延迟访问的数据和相关元数据并在此基础上为 S3 提供完整的文件系统语义包括一致性、文件锁和 POSIX 权限。可以把它理解为AWS 在对象存储之上增加了一层基于 EFS 的文件系统访问面使原本只能通过对象接口访问的数据也能以目录、文件和挂载点的形式被计算节点直接使用而文件系统与 S3 之间的数据变化则由服务在后台自动同步。基于这种架构S3 Files 并不会搬迁全量数据而是只将当前工作集中的一部分数据按需放到高性能层中而数据的“Source of Truth”依然保留在 S3 中。02 S3 Files 如何工作挂载、导入与同步机制对 S3 Files 来说挂载只是开始真正影响体验的是挂载之后的数据路径作用域如何确定首次访问会导入什么哪些请求会进入高性能层写入后又会如何同步回 S3。这些机制也直接决定了后文要讨论的性能边界与成本结构。以 EC2 挂载现有 S3 bucket 为例真正需要看清的不是挂载命令本身而是挂载之后数据会如何被导入、访问与同步。下面是几个关键的技术细节与步骤。a) 先确定作用域导入全量 S3 桶还是指定部分目录两者皆可。 S3 Files 支持将整个 S3 存储桶作为文件系统挂载也支持通过 Prefix前缀 限制作用域例如只挂载s3://my-bucket/data/ml/目录下。对于包含数千万个对象的庞大 S3 桶尤为重要因为过大的作用域会增加元数据同步的负担。在计算节点上使用 S3 Files 时AWS 提供了定制的挂载客户端amazon-efs-utils。挂载时使用的并不是存储桶名称而是 AWS 为 S3 Files 分配的 file system ID。创建一个本地挂载目录并使用专用的s3files文件系统类型进行挂载sudo yum -y install amazon-efs-utils sudo mkdir /mnt/s3files sudo mount -t s3files fs-1234567890abcdef0:/ /mnt/s3files如果只希望访问某个子目录也可以在挂载路径中进一步指定。但从实践上看更推荐在创建 S3 Files 时就把作用域限定到明确的 prefix而不是在一个过大的存储桶上再做后置控制。b) 首次访问时会发生什么导入触发方式与大小阈值S3 Files 并不会在挂载后立即把整个数据集搬入高性能层。它的数据导入由访问事件触发默认模式是ON_DIRECTORY_FIRST_ACCESS当你第一次访问某个目录时系统会导入该目录下文件的元数据并将符合条件的小文件数据异步导入 EFS 高性能层。如果配置为ON_FILE_ACCESS则首次遍历目录时只导入元数据只有在文件第一次被实际读取时数据才会进入高性能层。这种方式更节省空间和导入成本但首读延迟也会更高。这里最关键的控制参数是sizeLessThan。默认情况下只有小于 128 KB 的文件才会在导入时进入高性能层更大的文件通常只导入元数据内容仍然主要通过 S3 获取。换句话说S3 Files 优先优化的是小文件和低延迟访问而不是把所有数据都预热到高性能层中。对于 AI 训练这类以 10 MB 级图片、音视频文件为主的数据集来说这一点尤其关键即使完成了目录遍历这些大文件在默认配置下也未必会真正进入高性能层。c) 同步周期与冲突解决机制S3 Files 会在后台自动维护文件系统与 S3 之间的双向同步。S3 侧发生变化后文件系统视图会随之更新而在计算节点上的写入则会先落到 EFS 高性能层再由后台批量同步回 S3。默认情况下系统会对修改进行一段时间的聚合再执行回写。冲突处理的原则也很明确S3 始终是 Source of Truth。如果文件系统侧的修改尚未同步回 S3而对应对象已经在 S3 中被其他应用更新系统会以 S3 中的最新版本为准并将冲突文件移入.s3files-lostfound-*目录。03 S3 Files 的性能边界与成本结构上一节解释的是 S3 Files 如何运行这一节进一步讨论的则是这种运行方式会带来怎样的性能边界与成本结构。高性能层占用、大文件读取路径、写入流转以及局部更新和目录操作带来的放大效应是实际选型中最需要重点考量的四个方面。a) EFS 高性能层的占用、回收与成本S3 Files 的高性能层并不是按容量上限做 LRU 淘汰而是按访问时间进行生命周期管理。默认情况下已同步到 S3 且 30 天未被读取的数据会从 EFS 高性能层中移除这一时间由daysAfterLastAccess控制可配置范围为 1–365 天。这意味着它的成本取决于有多少数据需要驻留在 EFS 中以及驻留多久。如果工作集很大且长期保持活跃相关费用就会持续上升。b) 大文件直读与随机读其实是客户端在“穿透”读取S3 Files 对大文件的处理并不是把所有读取都留在 EFS 高性能层中完成。默认情况下sizeLessThan的值为 128 KB它决定的是哪些文件会在导入时把数据放入高性能层而对于已经同步到 S3 的数据128 KB 及以上的读取会直接从 S3 流式返回。也就是说S3 Files 的优化重点更偏向小文件和低延迟访问而不是让大文件读取长期稳定命中高性能层。这条直读路径依赖于计算资源本身具备读取源存储桶的权限。AWS 官方文档明确要求相关角色拥有s3:GetObject和s3:GetObjectVersion等权限否则客户端就无法直接从 S3 读取数据。c) 顺序写的代价大规模写入会引入额外流转成本S3 Files 的写路径并不是直接落到 S3。所有写操作都会先进入 EFS 高性能层再由后台同步回 S3。这意味着如果你的场景会持续产生大量结果数据例如顺序写入数百 TB 的训练产物或分析结果那么这些数据在流经 S3 Files 时会额外引入两类成本数据流转成本写入先进入高性能层随后再同步回 S3。相比直接写入 S3这条路径会多出一层中间流转开销。短期驻留成本数据同步完成后并不会立刻从高性能层中移除而是要等到满足过期条件后才会清理。默认情况下这意味着大批量写入产生的临时数据可能在一段时间内持续占用 EFS 容量。以某一区域当前价格为例写入 EFS 约为 $0.06/GB后台同步回 S3 的读取约为 $0.03/GB仅数据流转这一层每 1 TB 写入就大约会多出 $90 的附加成本。如果这些数据在同步完成后仍然继续驻留在 EFS 中还会进一步产生对应的高性能层存储费用。这也是为什么S3 Files 更适合读取现有数据而不适合长期承接大规模、持续性的结果写入。d) 局部更新与目录操作对象模型带来的放大效应S3 Files 底层不对数据进行切块而是尽量保持文件与 S3 对象之间的直接映射。这带来的代价是一旦涉及大文件的局部随机写或追加写应用层看起来只是一次很小的更新底层同步回 S3 时却更容易放大为显著的对象写入与版本开销。例如用户通过 S3 Files 在一个100 GB的lmdb文件中追加了一条100 KB的图片 key应用侧看到的只是一次很小的写入但这类修改并不会立刻回写到 S3而是会在大约 60 秒内先做聚合再同步回存储桶。它不会像块存储那样只改动一个离散块而更可能放大为对象写入、同步时延和版本存储成本。文件越大、修改越频繁这种代价就越值得警惕。目录重命名同样受 S3 扁平命名空间限制。S3 本身没有传统文件系统中的目录元数据因此执行rename或mv时S3 Files 不能只改一条元数据而是必须在 S3 侧为目录中的每个文件写入新对象并删除旧对象。对于拥有千万级对象的目录这会显著拉长同步时间并增加 S3 请求成本在同步完成前文件系统视图与 S3 视图之间还可能暂时不完全一致。总体来看S3 Files 的优势在于原生接入、零数据迁移以及对现有 S3 资产的良好兼容。它的代价则在于一旦场景转向大文件读取、持续写入、频繁局部更新或大目录操作性能和成本都会更快被放大。也正因为如此S3 Files 的优势更适合发挥在轻量共享访问场景中而在训练、数据生产和大规模分析等重负载场景下它的代价往往会更早暴露出来。04 JuiceFS vs S3 Files两种不同的架构思路前一节已经看到S3 Files 的很多边界并非偶然而是这类方案的共性结果。无论是早期的 s3fs、主打高吞吐读取的 Mountpoint for Amazon S3还是今天的 S3 Files它们都尽量保持文件与 S3 对象之间的直接映射以换取对现有 S3 数据的透明访问能力。这条路线的优势是透明和低改造代价则是先天受制于 S3 的对象模型。这也是为什么目录操作更容易退化为对象级请求大文件的局部更新也更容易演化为写放大、同步延迟和额外成本。也正因为如此JuiceFS 与这类方案的差异并不是某个功能点或单项指标的差别而是两条架构路线的根本区别。JuiceFS 不是“把 S3 挂出来用”的访问层而是构建在对象存储之上的云原生分布式文件系统。它采用数据与元数据解耦的架构文件数据存放在底层对象存储中元数据则由高性能键值数据库独立管理因此更适合承接训练、分析和数据生产等更重的生产型负载。为了让大家能更直观地进行架构选型我们从底层架构到高阶特性将 JuiceFS 与 S3 Files 进行了全方位对比对比维度JuiceFSAmazon S3 Files整体架构数据与元数据分离文件切块后写入对象存储基于 EFS 代理数据不切块1:1 动态根据设置的文件大小来映射对象默认128KB核心成本软件开源免费主要成本来自对象存储、元数据引擎和缓存资源除 S3 存储外需额外支付 EFS 存储费($0.30/GB)及数据读写 Sync 费读写放大(随机写)部分场景极低。数据切块后局部随机写通常只更新受影响的数据块无需重写全量数据数据生产场景会很高大文件随机修改会导致整个对象的重传重写冷热分层策略基于容量与访问热度将热数据自动预热至计算节点的本地盘/内存缓存中基于文件大小与访问时间。小文件(128K)热数据缓存在 EFS大文件绕过 EFS 直接读写 S3小文件性能依赖全内存的独立元数据引擎(Redis/TiKV 等)更适合大量小文件与元数据操作依赖 EFS 性能与 NFS 协议大文件吞吐可结合本地 NVMe / 内存缓存提升吞吐依赖 EFS 网关或 S3 直连性能大规模并行吞吐与容量配额绑定缓存一致性强一致性 (Close-to-open)。由独立元数据服务统一仲裁NFS Close-to-open。但遇到底层 S3 和文件系统并发修改冲突时本地 EFS 数据会被丢弃至 lostfoundS3 强行作为 TruthPOSIX 兼容性几乎 100% 兼容。 支持 Hard Links、原子级 Rename、各类锁语义支持 NFSv4.1/4.2 子集。 不支持硬链接(Hard links)、不支持原子重命名权限管理支持标准 POSIX 权限、ACL、Extended ACL 等多种鉴权支持标准 POSIX 权限、ACL、Extended ACL 等多种鉴权加密与安全传输加密、静态加密、并提供国密支持传输级 TLS 加密、静态 SSE-KMS 密钥加密AI 场景优化深度优化了 LMDB、Safetensors 等 AI 常见格式的 mmap 读取与本地预热机制无专门针对 AI 格式的底层优化依赖基础文件流式读
工作机制、性能边界与 JuiceFS 对比
发布时间：2026/7/7 4:27:29
层实现看S3 Files 使用 Amazon EFSElastic File System作为托管的高性能存储层用来承接需要低延迟访问的数据和相关元数据并在此基础上为 S3 提供完整的文件系统语义包括一致性、文件锁和 POSIX 权限。可以把它理解为AWS 在对象存储之上增加了一层基于 EFS 的文件系统访问面使原本只能通过对象接口访问的数据也能以目录、文件和挂载点的形式被计算节点直接使用而文件系统与 S3 之间的数据变化则由服务在后台自动同步。基于这种架构S3 Files 并不会搬迁全量数据而是只将当前工作集中的一部分数据按需放到高性能层中而数据的“Source of Truth”依然保留在 S3 中。02 S3 Files 如何工作挂载、导入与同步机制对 S3 Files 来说挂载只是开始真正影响体验的是挂载之后的数据路径作用域如何确定首次访问会导入什么哪些请求会进入高性能层写入后又会如何同步回 S3。这些机制也直接决定了后文要讨论的性能边界与成本结构。以 EC2 挂载现有 S3 bucket 为例真正需要看清的不是挂载命令本身而是挂载之后数据会如何被导入、访问与同步。下面是几个关键的技术细节与步骤。a) 先确定作用域导入全量 S3 桶还是指定部分目录两者皆可。 S3 Files 支持将整个 S3 存储桶作为文件系统挂载也支持通过 Prefix前缀 限制作用域例如只挂载s3://my-bucket/data/ml/目录下。对于包含数千万个对象的庞大 S3 桶尤为重要因为过大的作用域会增加元数据同步的负担。在计算节点上使用 S3 Files 时AWS 提供了定制的挂载客户端amazon-efs-utils。挂载时使用的并不是存储桶名称而是 AWS 为 S3 Files 分配的 file system ID。创建一个本地挂载目录并使用专用的s3files文件系统类型进行挂载sudo yum -y install amazon-efs-utils sudo mkdir /mnt/s3files sudo mount -t s3files fs-1234567890abcdef0:/ /mnt/s3files如果只希望访问某个子目录也可以在挂载路径中进一步指定。但从实践上看更推荐在创建 S3 Files 时就把作用域限定到明确的 prefix而不是在一个过大的存储桶上再做后置控制。b) 首次访问时会发生什么导入触发方式与大小阈值S3 Files 并不会在挂载后立即把整个数据集搬入高性能层。它的数据导入由访问事件触发默认模式是ON_DIRECTORY_FIRST_ACCESS当你第一次访问某个目录时系统会导入该目录下文件的元数据并将符合条件的小文件数据异步导入 EFS 高性能层。如果配置为ON_FILE_ACCESS则首次遍历目录时只导入元数据只有在文件第一次被实际读取时数据才会进入高性能层。这种方式更节省空间和导入成本但首读延迟也会更高。这里最关键的控制参数是sizeLessThan。默认情况下只有小于 128 KB 的文件才会在导入时进入高性能层更大的文件通常只导入元数据内容仍然主要通过 S3 获取。换句话说S3 Files 优先优化的是小文件和低延迟访问而不是把所有数据都预热到高性能层中。对于 AI 训练这类以 10 MB 级图片、音视频文件为主的数据集来说这一点尤其关键即使完成了目录遍历这些大文件在默认配置下也未必会真正进入高性能层。c) 同步周期与冲突解决机制S3 Files 会在后台自动维护文件系统与 S3 之间的双向同步。S3 侧发生变化后文件系统视图会随之更新而在计算节点上的写入则会先落到 EFS 高性能层再由后台批量同步回 S3。默认情况下系统会对修改进行一段时间的聚合再执行回写。冲突处理的原则也很明确S3 始终是 Source of Truth。如果文件系统侧的修改尚未同步回 S3而对应对象已经在 S3 中被其他应用更新系统会以 S3 中的最新版本为准并将冲突文件移入.s3files-lostfound-*目录。03 S3 Files 的性能边界与成本结构上一节解释的是 S3 Files 如何运行这一节进一步讨论的则是这种运行方式会带来怎样的性能边界与成本结构。高性能层占用、大文件读取路径、写入流转以及局部更新和目录操作带来的放大效应是实际选型中最需要重点考量的四个方面。a) EFS 高性能层的占用、回收与成本S3 Files 的高性能层并不是按容量上限做 LRU 淘汰而是按访问时间进行生命周期管理。默认情况下已同步到 S3 且 30 天未被读取的数据会从 EFS 高性能层中移除这一时间由daysAfterLastAccess控制可配置范围为 1–365 天。这意味着它的成本取决于有多少数据需要驻留在 EFS 中以及驻留多久。如果工作集很大且长期保持活跃相关费用就会持续上升。b) 大文件直读与随机读其实是客户端在“穿透”读取S3 Files 对大文件的处理并不是把所有读取都留在 EFS 高性能层中完成。默认情况下sizeLessThan的值为 128 KB它决定的是哪些文件会在导入时把数据放入高性能层而对于已经同步到 S3 的数据128 KB 及以上的读取会直接从 S3 流式返回。也就是说S3 Files 的优化重点更偏向小文件和低延迟访问而不是让大文件读取长期稳定命中高性能层。这条直读路径依赖于计算资源本身具备读取源存储桶的权限。AWS 官方文档明确要求相关角色拥有s3:GetObject和s3:GetObjectVersion等权限否则客户端就无法直接从 S3 读取数据。c) 顺序写的代价大规模写入会引入额外流转成本S3 Files 的写路径并不是直接落到 S3。所有写操作都会先进入 EFS 高性能层再由后台同步回 S3。这意味着如果你的场景会持续产生大量结果数据例如顺序写入数百 TB 的训练产物或分析结果那么这些数据在流经 S3 Files 时会额外引入两类成本数据流转成本写入先进入高性能层随后再同步回 S3。相比直接写入 S3这条路径会多出一层中间流转开销。短期驻留成本数据同步完成后并不会立刻从高性能层中移除而是要等到满足过期条件后才会清理。默认情况下这意味着大批量写入产生的临时数据可能在一段时间内持续占用 EFS 容量。以某一区域当前价格为例写入 EFS 约为 $0.06/GB后台同步回 S3 的读取约为 $0.03/GB仅数据流转这一层每 1 TB 写入就大约会多出 $90 的附加成本。如果这些数据在同步完成后仍然继续驻留在 EFS 中还会进一步产生对应的高性能层存储费用。这也是为什么S3 Files 更适合读取现有数据而不适合长期承接大规模、持续性的结果写入。d) 局部更新与目录操作对象模型带来的放大效应S3 Files 底层不对数据进行切块而是尽量保持文件与 S3 对象之间的直接映射。这带来的代价是一旦涉及大文件的局部随机写或追加写应用层看起来只是一次很小的更新底层同步回 S3 时却更容易放大为显著的对象写入与版本开销。例如用户通过 S3 Files 在一个100 GB的lmdb文件中追加了一条100 KB的图片 key应用侧看到的只是一次很小的写入但这类修改并不会立刻回写到 S3而是会在大约 60 秒内先做聚合再同步回存储桶。它不会像块存储那样只改动一个离散块而更可能放大为对象写入、同步时延和版本存储成本。文件越大、修改越频繁这种代价就越值得警惕。目录重命名同样受 S3 扁平命名空间限制。S3 本身没有传统文件系统中的目录元数据因此执行rename或mv时S3 Files 不能只改一条元数据而是必须在 S3 侧为目录中的每个文件写入新对象并删除旧对象。对于拥有千万级对象的目录这会显著拉长同步时间并增加 S3 请求成本在同步完成前文件系统视图与 S3 视图之间还可能暂时不完全一致。总体来看S3 Files 的优势在于原生接入、零数据迁移以及对现有 S3 资产的良好兼容。它的代价则在于一旦场景转向大文件读取、持续写入、频繁局部更新或大目录操作性能和成本都会更快被放大。也正因为如此S3 Files 的优势更适合发挥在轻量共享访问场景中而在训练、数据生产和大规模分析等重负载场景下它的代价往往会更早暴露出来。04 JuiceFS vs S3 Files两种不同的架构思路前一节已经看到S3 Files 的很多边界并非偶然而是这类方案的共性结果。无论是早期的 s3fs、主打高吞吐读取的 Mountpoint for Amazon S3还是今天的 S3 Files它们都尽量保持文件与 S3 对象之间的直接映射以换取对现有 S3 数据的透明访问能力。这条路线的优势是透明和低改造代价则是先天受制于 S3 的对象模型。这也是为什么目录操作更容易退化为对象级请求大文件的局部更新也更容易演化为写放大、同步延迟和额外成本。也正因为如此JuiceFS 与这类方案的差异并不是某个功能点或单项指标的差别而是两条架构路线的根本区别。JuiceFS 不是“把 S3 挂出来用”的访问层而是构建在对象存储之上的云原生分布式文件系统。它采用数据与元数据解耦的架构文件数据存放在底层对象存储中元数据则由高性能键值数据库独立管理因此更适合承接训练、分析和数据生产等更重的生产型负载。为了让大家能更直观地进行架构选型我们从底层架构到高阶特性将 JuiceFS 与 S3 Files 进行了全方位对比对比维度JuiceFSAmazon S3 Files整体架构数据与元数据分离文件切块后写入对象存储基于 EFS 代理数据不切块1:1 动态根据设置的文件大小来映射对象默认128KB核心成本软件开源免费主要成本来自对象存储、元数据引擎和缓存资源除 S3 存储外需额外支付 EFS 存储费($0.30/GB)及数据读写 Sync 费读写放大(随机写)部分场景极低。数据切块后局部随机写通常只更新受影响的数据块无需重写全量数据数据生产场景会很高大文件随机修改会导致整个对象的重传重写冷热分层策略基于容量与访问热度将热数据自动预热至计算节点的本地盘/内存缓存中基于文件大小与访问时间。小文件(128K)热数据缓存在 EFS大文件绕过 EFS 直接读写 S3小文件性能依赖全内存的独立元数据引擎(Redis/TiKV 等)更适合大量小文件与元数据操作依赖 EFS 性能与 NFS 协议大文件吞吐可结合本地 NVMe / 内存缓存提升吞吐依赖 EFS 网关或 S3 直连性能大规模并行吞吐与容量配额绑定缓存一致性强一致性 (Close-to-open)。由独立元数据服务统一仲裁NFS Close-to-open。但遇到底层 S3 和文件系统并发修改冲突时本地 EFS 数据会被丢弃至 lostfoundS3 强行作为 TruthPOSIX 兼容性几乎 100% 兼容。 支持 Hard Links、原子级 Rename、各类锁语义支持 NFSv4.1/4.2 子集。 不支持硬链接(Hard links)、不支持原子重命名权限管理支持标准 POSIX 权限、ACL、Extended ACL 等多种鉴权支持标准 POSIX 权限、ACL、Extended ACL 等多种鉴权加密与安全传输加密、静态加密、并提供国密支持传输级 TLS 加密、静态 SSE-KMS 密钥加密AI 场景优化深度优化了 LMDB、Safetensors 等 AI 常见格式的 mmap 读取与本地预热机制无专门针对 AI 格式的底层优化依赖基础文件流式读
 获取与实战)
