ZeroFS 与 Amazon S3 Files 对比

# ZeroFS 与 Amazon S3 Files 对比 来源：https://www.zerofs.net/blog/zerofs-vs-aws-s3-files/ Amazon S3 Files 和 ZeroFS 都对外提供基于对象存储的 POSIX 文件系统，但同样的接口背后隐藏着截然不同的存储桶布局。选择的关键在于存储桶的角色：如果文件必须保持为普通 S3 对象，则 S3 Files 保留了这种身份；如果存储桶可以作为内部持久化层，那么 ZeroFS 则用直接 S3 访问权换取打包、压缩和客户端加密。 ## 存储布局 S3 Files 基于 Amazon EFS (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files.html) 构建，其核心特性是：挂载点上的 `images/cat.jpg` 对应存储桶中同样的键，变更双向流动。活跃数据和元数据位于 AWS 称为"高性能存储"的低延迟层级。 这种"一文件一对象"的身份识别在 ZeroFS 的存储格式 (https://www.zerofs.net/docs/architecture) 中被有意舍弃。元数据存储于 LSM 树中；文件内容被分割为区段，经过压缩和加密后，打包为不可变的段对象。S3 客户端看到的是不透明的内部布局，而非挂载的文件。 `` flowchart TB subgraph CLIENTS["客户端层"] NFS["NFS 客户端"] P9["9P 客户端"] NBD["NBD 客户端"] WEB["Web 浏览器"] end subgraph CORE["ZeroFS 核心"] NFSD["NFS 服务器"] P9D["9P 服务器"] NBDD["NBD 服务器"] WEBUI["Web UI"] VFS["虚拟文件系统"] SEG["段存储：已压缩、加密的文件数据帧"] SLATE["LSM 树：元数据和32字节区段指针"] CACHE["本地缓存"] NFSD --> VFS P9D --> VFS NBDD --> VFS WEBUI --> VFS VFS --> SEG VFS --> SLATE SEG --> CACHE SLATE --> CACHE end subgraph BACKEND["存储后端"] SEGOBJ["不可变段对象"] SSTS["元数据 SST 和清单"] S3["S3 对象存储"] CACHE --> SEGOBJ CACHE --> SSTS SEGOBJ --> S3 SSTS --> S3 end NFS --> NFSD P9 --> P9D NBD --> NBDD WEB --> WEBUI `` ZeroFS 将文件数据和文件系统元数据保持在不同的路径上，直到两者都到达对象存储。两种挂载都使用客户端页面缓存。下面的写入路径从客户端向服务器发送写入之后开始。 | 特性 | Amazon S3 Files | ZeroFS | |------|----------------|--------| | 存储模型 | AWS 管理的高性能存储，与存储桶同步；内部布局未文档化 | LSM 树和对象存储上的不可变数据段 | | 对象布局 | 一个文件映射为一个 S3 对象 | 元数据在 LSM 树中；文件数据帧打包到段中 | | 写入路径（客户端缓存后） | NFS 写入高性能存储，立即持久；写入空闲后异步导出到 S3 | 通过 9P，`fsync` 在返回成功前将数据段上传并刷新 LSM 元数据到对象存储 | | 冷读和预读 | Linux NFS 预读、目录元数据导入、可选的小文件导入，或直接 S3 读取 | LSM 查找，然后自适应预取对象和跨段帧 | | 通过 S3 API 访问文件 | 是；文件系统变更在异步导出后可见 | 否；读取文件需要 ZeroFS 和加密密码 | | 客户端接口 | NFS 4.1/4.2 | 9P 或 NFS 用于文件；NBD 用于块 | | 对象存储选择 | Amazon S3 | Amazon S3、兼容 S3 的存储、Azure Blob 或 Google Cloud Storage | | 成本模型 | S3 加上高性能存储、文件访问和同步费用 | 对象存储和请求费用，加上运行 ZeroFS 的计算和缓存开销 | ## 对象互操作性 保持这种一对一映射意味着通过挂载写入的文件最终会成为普通的 S3 对象 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html)。导出在无写入操作后 60 秒开始，因此持续写入会推迟 S3 可见性。导出完成后，现有工具可以使用 `GetObject` 读取该对象，并且 S3 侧的变更会回流到文件系统中。如果双方在同步前修改了同一个文件，S3 胜出，文件侧版本移至 `lost+found`。 ZeroFS 路径名无法通过 S3 API 获取，也无法将段作为 Parquet 扫描。作为交换，小文件既不需要一个数据对象，也不需要每次 PUT：它们的区段被压缩、加密并打包在一起。存储桶和原始本地缓存包含密文，因此挂载或恢复需要 ZeroFS 及其加密密码。加密文档 (https://www.zerofs.net/docs/encryption) 列出了仍然可见的结构元数据。 如果其他应用程序需要文件系统写入后立即通过 S3 可见，两种模型都无法提供：S3 Files 异步导出，而 ZeroFS 从不通过 S3 API 暴露挂载的文件。 ## 冷访问 第一次访问 S3 Files 可能触发导入：列出目录会加载每个对象的元数据，并异步复制导入阈值以下（默认 128 KiB）的文件到高性能存储。AWS 表示首次列出 1000 个对象可能需要几秒钟 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html)。较大的文件保留在 S3 中，并且至少 1 MiB 的读取直接转到 S3 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-performance.html)。 ZeroFS 则是通过读取和上传填充本地 RAM 和磁盘缓存 (https://www.zerofs.net/docs/caching)。新密封的段从已获得的字节进入缓存，因此读后写不需要 GET；缓存不是回写式的，写入仍然在段密封和元数据刷新时到达对象存储。冷缺失通过 LSM 树解析请求的区段，并将相邻帧合并为范围 GET。它在不导入文件其余部分或目录中每个小文件的情况下支付第一次对象存储往返；一旦工作集适合本地，数据读取将产生很少的 S3 请求。 两种路径都为顺序访问添加了预读：ZeroFS 在段对象内部和跨段对象预取，而 S3 Files 依赖 Linux NFS 预读及其直接 S3 路由。 ## 成本 两种情况都会产生 S3 存储和请求费用。S3 Files 还对其高性能存储层级收费：每 GB-月的驻留存储以及每 GB 的读取和写入。发布时 AWS 定价示例 (https://aws.amazon.com/s3/pricing/) 使用的费率如下： | S3 Files 费用 | AWS 示例中使用的费率 | 适用情况 | |----------------|---------------------|----------| | 高性能存储 | 每 GB-月 $0.30 | 文件有最小计费大小 10 KiB | | 文件读取 | 每 GB $0.03 | 从高性能存储读取，包括导出到 S3 | | 文件写入 | 每 GB $0.06 | 写入高性能存储，包括从 S3 导入 | 高性能存储中的驻留量取决于配置的导入阈值和过期窗口 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization-customizing.html)。列出操作会导入元数据和符合条件的小文件，读取可能加载更多数据，并且文件元数据不会过期 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html)。导入按文件系统写入计量，导出按读取计量；最小操作大小 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-metering.html) 对于文件数据是 32 KiB，对于元数据是 4 KiB。AWS 在 CloudWatch (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-monitoring-cloudwatch.html) 中报告驻留字节和索引节点，但仅靠存储桶总大小无法预测账单。 ### 示例模型：存储 10,000 GiB 并读取一次 **这是一个说明性场景，并非一般成本比较。** 它使用 `us-east-1` 区域 S3 标准存储中 10,000 个 AWS 计费 GB（GiB）的逻辑数据，价格为每 GB-月 $0.023 (https://aws.amazon.com/s3/pricing/)。直接读取情况假设从 S3 中已存在的数据进行 1 MiB 读取；驻留读取情况假设读取小于 1 MiB，并且所有数据也驻留在高性能存储中。互联网出站流量不包括在内。 | 情况 | 存储/月 | 读取一次 | 说明性子总计 | |------|---------|---------|--------------| | ZeroFS（2:1 压缩） | ~$115 + 开销 | S3 GETs | ~$115 + 基础设施 | | ZeroFS（1:1 压缩） | ~$230 + 开销 | S3 GETs | ~$230 + 基础设施 | | S3 Files（1 MiB 直接读取） | ~$230 + 元数据 | ~$1.17 + S3 GETs | ~$231 + 元数据和请求 | | S3 Files（小驻留读取） | $3,230 | $300 | $3,530 + $600（如果导入） | ZeroFS 的数据是估算值：压缩减少有效载荷字节，而元数据、临时压缩数据和请求会增加成本。在理想的 8 MiB GET 大小下，读取文件数据在 2:1 压缩时成本约为 $0.26，在 1:1 压缩时约为 $0.51，不包括元数据和短/随机读取。ZeroFS 还需要一台服务器（高可用性需要两台）以及本地磁盘缓存；每个节点除了配置的内存缓存外，还需要大约 2 GB 的 RAM。因此，对于大文件流式传输，S3 Files 可能成本更低。当数据被导入或写入高性能存储时，差异会更大：通过 S3 Files 写入 10,000 GiB 会增加 $600 的文件系统写入和 $300 的导出费用，而一个月的驻留费用增加 $3,000。 实际成本取决于文件数量、压缩比、I/O 大小、驻留时间、`fsync` 频率和基础设施。S3 Files 还要求启用存储桶版本控制 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html)，因此非当前版本需要适当的生命周期规则。 ## `fsync` 与 S3 可见性 在 S3 Files 中，持久性和 S3 可见性是独立的事件。写入高性能存储是立即持久的 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-performance.html)，但导出仅在无写入操作约 60 秒后开始 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html)；调用 `fsync` 不会使对象立即通过 S3 API 可见。ZeroFS 没有第二个可见性事件，因为没有导出步骤。通过 9P，成功的 `fsync` (https://www.zerofs.net/docs/durability) 在对象存储确认数据段及其 LSM 元数据后返回，使得文件在冷重启后可以恢复。 ## 重命名 S3 没有目录，也没有针对通用用途存储桶的原子重命名 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-synchronization.html)。S3 Files 在挂载点上执行重命名，然后将每个受影响的对象复制到新键并删除旧键；在目录重命名期间，两个前缀都可能可见。AWS 表示同步 100,000 个重命名的文件需要几分钟 (https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files-performance.html)。ZeroFS 仅更改其 LSM 目录项，每个后代无需复制，且不向对象客户端暴露 S3 前缀。 --- 挂载点看起来可能相似，但存储桶做出了不同的承诺：S3 Files 为周围的 S3 生态系统保留了普通对象；ZeroFS 则将对象存储视为文件系统的私有基础层。