开源项目ZeroFS最近在Hacker News发布,主打一句话:把任何S3兼容的存储桶,通过NFS、9P挂载成POSIX文件系统,或者通过NBD挂载成裸块设备。官方甩出的数字很扎眼——CI里跑了8,662项POSIX兼容性测试,warm cache随机读延迟1.6微秒,小写入平均延迟0.83毫秒,单个文件系统最大能到16 EiB。演示视频里,三个S3区域组成一个ZFS镜像,断掉一个区域,数据照样能读。
这套数字堆出来的印象是"生产级可靠"。但读完官网你会发现,它绕开了一个更根本的问题:这到底是一块被搬到S3上的本地盘,还是一套真正的分布式文件系统?
测试证明了语义正确,没证明多写者安全
ZeroFS的CI体系确实扎实:pjdfstest测POSIX权限语义,xfstests是ext4、XFS自己在用的内核测试集,还找Jepsen跑了模型检验和故障注入。官网明说,这套流程验证的是"一个ZeroFS实例对外提供文件语义时对不对"。
- 风险.官网和文档没有正面回答一个问题——多个客户端能不能同时写同一个bucket。9P和NFS挂载的场景描述,读起来更像单进程、单写者对外服务多个读者,而不是多节点并发写入同一份数据。
这不是吹毛求疵。地理分布的那个演示——三个区域的NBD设备组成ZFS镜像——本质上是ZFS在做冗余,不是ZeroFS在做分布式扩展。每个区域的ZeroFS实例各自管一份完整拷贝,ZFS负责镜像同步和故障切换,这和"多个客户端并发写同一份数据"完全是两回事。
从s3fs到JuiceFS,行业早就在这道题上栽过跟头
把对象存储伪装成文件系统,不是新想法。早期的s3fs、goofys都是薄FUSE封装:s3fs官方文档自己承认不支持原子rename、不支持硬链接,多客户端之间没有协调机制;goofys干脆自称"POSIX-ish",文档写明fsync会被直接忽略。这两个项目的教训是——语义做得越简单,越容易在多写者场景下踩坑。
JuiceFS走的是另一条路:用独立的元数据服务管理文件树和锁,对象存储只存数据块。代价是多一套服务要运维,换来的是官方宣称的强一致性和全局文件锁,在一次pjdfstest测试里也几乎全数通过,只在少数时间戳边界case上失手。
ZeroFS的定位介于两者之间——它比s3fs、goofys认真得多,CI覆盖度也更高;但截至目前,它公布的vs JuiceFS基准对比页面,自己标注是在"legacy storage engine"(旧版引擎)上测得,新版本表现如何、多写者语义有没有变化,官网没有更新说明。Hacker News讨论区也有人对S3之上的随机I/O性能、以及分布式语义提出过质疑。
一万次CI通过,证明的是语义对,不是架构对。
谁该现在用,谁该再等等
对需要用S3替代EBS降本、workload以顺序写和单节点为主的团队——比如备份、归档、单实例数据库——ZeroFS的定位很清楚:文档也建议需要严格fsync语义时优先用9P而不是NFS,这本身就是一个诚实的边界提示。
- 结论.如果只是想把闲置数据从贵盘搬到S3省钱,ZeroFS现在就能试;如果需要多个节点同时写同一份数据,答案还没写在官网上。
对已经在用JuiceFS支撑多客户端共享存储的团队,现在没有理由迁移——ZeroFS更年轻,测试体系漂亮,但"多写者是否安全"这道题,项目方自己还没正面回答。接下来最该盯的,是新版引擎的基准会不会补上,以及第一批真实生产环境的长期反馈能不能出现。