文章摘要
ZeroFS是一个日志结构文件系统，可将S3兼容存储桶挂载为POSIX文件系统或原始块设备，支持NFS和9P协议。数据在上传前会进行压缩和加密，热读取通过本地缓存实现微秒级响应，最大文件系统容量达16 EiB。
文章总结
好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节并删除了与主题无关的安装命令和链接等元素。
标题：ZeroFS — 将S3作为主存储
核心概念： ZeroFS 是一个为 S3 设计的日志结构文件系统。它可以将兼容 S3 的对象存储桶，通过 NFS 和 9P 协议挂载为 POSIX 文件系统，或通过 NBD 协议挂载为原始块设备。
工作原理： 其引擎采用日志结构设计：写入操作会生成不可变的对象，而数据删除则通过压缩回收机制实现。数据在上传前会进行压缩和加密，热读取则来自本地缓存，响应时间可达微秒级。
性能与规模： - 在持续集成（CI）中通过了 8,662 项 POSIX 兼容性测试。 - 热缓存下的随机读取延迟为 1.6 微秒。 - 小文件写入的平均延迟为 0.83 毫秒。 - 最大文件系统大小可达 16 EiB。
验证与测试： ZeroFS 在公开的 CI 中运行了多套测试套件，包括： - POSIX 语义测试：每次变更都会运行 pjdfstest 套件，验证权限、所有权、链接和重命名行为。 - 内核文件系统测试：运行 xfstests 套件，这是 ext4 和 XFS 等文件系统自身用于验证的测试。 - 端到端测试：在 ZeroFS 块设备上构建 ZFS 池，并执行完整的数据校验，确保无校验错误。 - 压力测试：在 NFS、9P 和 FUSE 挂载点上并行编译 Linux 内核，模拟高并发写入压力。 - 模型化检查：使用 Jepsen 的本地文件系统套件，通过随机操作历史进行验证，并模拟服务器崩溃以检查恢复后状态的一致性。 - 故障注入下的故障转移：通过另一套 Jepsen 套件，在 MinIO 上运行主备模式，通过杀死、重启和暂停主节点来验证所有已确认的写入在故障转移后都能保留，且文件系统保持一致。
支持的协议：
- NFS：macOS、Linux、Windows 和 BSD 系统可直接使用自带的 NFS 客户端挂载，无需在客户端安装额外软件。
- 9P：比 NFS 更严格地遵循 POSIX 标准，fsync 操作会等待数据写入稳定存储后才返回。其附带的 FUSE 客户端无需 root 权限即可挂载，并能自动重连。
- NBD：提供原始块设备，可用于存放 ext4 文件系统、ZFS 池或虚拟机启动盘。新设备可在运行时动态添加，无需重启服务器。
地理分布： ZeroFS 可以跨 S3 区域构建 ZFS 镜像。每个 ZeroFS 实例将一个 S3 区域暴露为一个块设备，ZFS 将其视为普通磁盘，因此可以像设置任何其他池一样，创建跨大洲的镜像。当一个区域不可达时，池会降级，但数据仍可从其他两个区域获取。
存储引擎特性：
1. 始终加密：每个数据块在上传前都使用 XChaCha20-Poly1305 加密，数据密钥由用户密码通过 Argon2id 派生。
2. 压缩：数据在加密前使用 zstd 或 lz4 压缩，编解码器可在运行时动态切换，无需迁移数据。
3. 缓存：可配置的内存和磁盘缓存用于存储最近使用的数据块，热读取延迟为微秒级。
4. 检查点：可以创建命名检查点，捕获文件系统在某个时间点的状态，并可以只读方式挂载。
5. 只读副本：一个实例负责写入，其他只读实例可服务于同一存储桶，并自动同步写入者的变更。
6. TRIM 支持：文件系统或 ZFS 池的丢弃操作会释放相应的数据块，压缩过程会重新打包有效数据并删除 S3 中的空段，从而节省费用。
7. 不可变段：文件数据被打包成 32 KiB 的块，存储在不可变的段对象中，由独立的元数据索引寻址。这确保了检查点和只读副本能看到一致的存储桶视图。
8. 诚实的 fsync：成功的 fsync 意味着所有已确认的写入都已持久化到 S3。如果故障转移可能导致未刷新的写入丢失，下一次 fsync 会返回错误，而不是虚假的成功。
9. 高可用性：可选的备用实例会跟踪主实例，并在主实例故障时自动接管。当两者连接时，备用实例也会持有主实例已确认但尚未刷新的写入，从而在故障转移时保留这些数据。
Web UI： 通过启用一个配置项，ZeroFS 可以提供一个 Web 控制台，包含文件管理器、实时仪表盘和终端。文件管理器支持拖放上传文件和文件夹。
评论总结
根据评论内容，总结如下：
主要观点与论据：
对ZeroFS的质疑与批评
- 评论1（abtinf）认为将数据存储委托给“vibe coded”文件系统是不明智的。
- 评论5（iamalizaidi）直接评价“Seems purely vibecoded”，暗示其缺乏严谨性。
- 评论12（rockwotj）指出“sub-millisecond writes with data in S3 is false and impossible”，并批评基准测试未计时fsync，导致数据不可靠。
- 关键引用：
- “Entrusting data storage to a vibe coded filesystem seems imprudent.”
- “The sub-millisecond writes with data in S3 is false and impossible.”
技术实现与性能问题
- 评论7（coxley）担忧128 KiB分块大小导致S3读写操作成本远高于存储字节。
- 评论8（preetham_rangu）质疑LSM树方法在远程存储上的压缩暂停可能影响性能。
- 评论11（aniketsaini777）分析128 KiB分块在跨块读取时增加请求开销，并询问预取策略。
- 关键引用：
- “Read/write operations in object storage are far more expensive than stored bytes.”
- “The 128 KiB chunk size is an interesting tradeoff point… you're still paying per-request overhead on S3.”
与现有方案的比较
- 评论6（tmach32）认为直接让应用感知对象存储比抽象S3为文件系统更可靠，并提及JuiceFS、S3FS等。
- 评论20（dangoodmanUT）声称本地测试中ZeroFS性能远逊于Ceph，差距达1-2个数量级。
- 关键引用：
- “making your application object store-aware is a far surer bet than abstracting S3 behind the file system.”
- “ZeroFS performs horrifically… Ceph blows it out of the water.”
功能与设计缺陷
- 评论13（chillfox）质疑为何选择NFSv3而非更现代的v4。
- 评论10（ChocolateGod）指出早期版本元数据需存储在ZeroFS服务器上，导致高可用性困难。
- 关键引用：
- “I don’t get why they went for NFSv3, v4 is quite old…”
- “the first version of this required the metadata to be stored on the ZeroFS server, making HA kinda hard.”
潜在价值与改进方向
- 评论16（rapatel0）认为将S3视为块存储桶是构建可扩展文件系统的直观方法，但强调需说明持久性和故障窗口。
- 评论9（tribal808）指出关键差异化在于效率和安全性。
- 关键引用：
- “Treating s3 like a bucket of blocks seemed intuitive way build a scalable filesystem.”
- “your key differentiator needs to be efficiency and safety compared to other options.”
平衡性总结：
评论整体对ZeroFS持怀疑态度，主要批评其性能、成本、设计选择（如NFSv3、分块大小）及可靠性。少数评论认可其概念（如将S3作为块存储），但强调需在效率、安全性和故障处理上证明价值。技术对比中，JuiceFS、SeaweedFS、Ceph等被视为更成熟的替代方案。