RustFS 1.0 GA：别活成 MinIO 的样子

冯若航Pigsty 创始人，PostgreSQL 大法师，数据库老司机，云计算泥石流

RustFS 的老板李文凯是我朋友，奇绩创坛的校友——他们 S26，我 S22。昨晚他们发了 1.0 GA 版本，他找我今天写一篇帮他宣传宣传，还特意叮嘱：冯大，写得带点争议才有人看，再帮我们美言几句。

动笔之前，先把利益关系交代清楚。老冯呢，维护着一个 PostgreSQL 发行版 Pigsty，里面用到了 MinIO 作为对象存储。之前 MinIO 跑路，所以我自己维护着一个 Fork——Silo——从这个意义上说，我是 RustFS 的竞品。另一方面，我也确实不是非得要用哪一个对象存储，所以 Pigsty 也支持用 RustFS 替换 MinIO——替 RustFS 打好了 RPM/DEB 包，提供部署剧本，算是它的一个分发渠道。

校友、竞争对手、合作方，几种关系糅在一起。所以下面这些话里有挑刺，有祝贺，有些地方两者分不开。提供一个视角，大家自己判断。

MinIO 把机会送上门

9 月 11 日 UTC 傍晚，Docker Hub 上的 minio/minio 和 minio/mc 两个仓库消失了。访问 404，镜像拉不下来，一个拉取量超过 20 亿的仓库就这么没了，事发时也没见官方出来解释。Milvus、Grafana Mimir、DataHub、Plane、OpenCTI……一批依赖它的项目陆续报错。有人连夜改指 quay.io，有人干脆换掉。

GitHub 上的 MinIO 仓库倒是还在，挂着六万多颗星，README 却已经写上“本仓库不再维护”，把用户导向 AIStor Free 和 AIStor Enterprise。前者也不是大家熟悉的那个开源发行版，而是受专有 EULA 约束的产品。

五天之后，9 月 16 日，我维护的 Silo 发了正式版。当晚九点，RustFS 发了 1.0 GA。两个项目都在接 MinIO 撒手不管的活，但接的不是同一摊活。

存量和增量

Silo 要解决的是老用户的问题。你手里有几个 PB 的数据躺在 MinIO 里，几套 Ansible 剧本，一堆写死的 mc admin 脚本。这时候谁跟你说“我们重新设计了一个更先进的对象存储”，你未必高兴。你要的很可能就一句话：什么都别动，把 CVE 和正确性问题修了，把镜像给我。

RustFS 面对的用户更愿意往前走一步。新项目、新集群，想离开 AGPL，或者想找一个还在积极开发、有路线图、有商业支持的对象存储，都有理由看看它。两边当然有重叠，下面的迁移测试就能说明。但我做 Silo，首先是让自己和现有用户手里的 MinIO 继续好好跑，没打算跟每一个新对象存储争高下。

RustFS 要是真能做好，我乐得换过去，少操一份心。

确实做了不少东西

按官方公布的数据，RustFS 2024 年 2 月写下第一行代码，2025 年 7 月开源，2026 年 4 月 Beta，8 月 RC，9 月 GA。开源 14 个月，6600 多次提交，135 个版本，180 多位贡献者，32k Star。官方称全球安装量已达 270 万，七成以上来自欧美，Docker Hub 拉取量超过一千万，AI、能源、金融、云计算行业都有了付费客户。

数字挺漂亮，不过拉取量得放在一起看：MinIO 刚消失的那个仓库超过 20 亿，RustFS 刚过一千万，差着两个数量级。拉取量证明不了可靠性，但背后的使用时间和场景积累，是跳不过去的。“MinIO 平替”四个字不轻，RustFS 刚把手搭上去，1.0 才是开始接受考验。

官方给了几个案例：法国 AI 公司 TwinLabs，4×2 拓扑跑在 NixOS 上，CTO 从 Alpha 阶段就一路反馈问题；乌兹别克斯坦的云服务商 HyperApp，拿它给客户切实例；还有孟加拉的金融企业，坦桑尼亚的国家银行。

我看到的这些案例，容量主要在几十到上百 TB。愿意在 Alpha 阶段上生产，遇到问题还认真提 Issue，这样的早期用户很珍贵。但几十 TB 跑得好，不能直接外推到几个 PB。容量只是一个维度，对象数量、故障频率、重建时间、多池扩容、长期混合负载，每一项都会把问题放大。PB 级这一关，公开材料里目前还缺证据。

这一关我看得重，是因为俺真拿 MinIO 搭过 25 PB 的池子，当年应该是国内最大的 MinIO 部署，跑了几年真实生产，那个量级上什么地方会出事，多少有数。MinIO 跑路后我宁可 Fork 也要接着用，也是这个原因。当然现在没那个条件了。

不过对愿意钻研的团队来说，PB 级只是时间问题。文凯写过一本书，《从 MinIO 到企业级云存储》。先给 MinIO 写教材，再做 MinIO 的替代品，算是把研究对象做成了竞争对手。

先说值得夸的

Apache 2.0，是个实在的理由。 要把对象存储装进自己产品、交付给客户，又对 AGPL 有顾虑的团队，光这一条就足够认真考虑 RustFS。不过宽松许可证和长期开放是两件事，后面还要说。

S3 Tables 完全开源。 官方说 RustFS 内置了 Iceberg REST Catalog，而且明确写了“此功能完全开源”。对照一下，MinIO 的 AIStor Tables 今年 2 月 GA，放在企业版里。这项功能我还没测，但把它放进开源版这个选择本身就是实打实的加分，比喊几句“拥抱社区”管用。

功能清单已经相当齐全。 IAM、OIDC、KMS、SSE、STS、mTLS、审计；分布式、池扩容、再平衡、自愈、站点复制、桶复制；生命周期、分层、事件通知，常见能力基本列齐了。官方说“功能层面基本追平 MinIO 开源版本”，单看清单不算离谱。至于每一个“支持”能支持到什么程度，得逐项验。

最后一条，也是我这次最想夸的：对 MinIO 磁盘格式的兼容，确实做出了东西。 官方说 MinIO 用户可以直接替换二进制完成迁移。这话我拿来测了一轮，倒是不假。

换个二进制就能迁移？

先放结论：未加密数据可以全停替换，写入新数据之后还能回滚回 MinIO。 比我预期好得多。

测试用的是 RustFS 1.0.0 官方二进制，三个构建：x86_64 GNU、x86_64 musl、ARM64 GNU。源端分别是 MinIO RELEASE.2025-09-07 和 Silo。拓扑测了三种：单机单盘、单机四盘、四进程模拟四节点。每个场景准备 5 个桶、125 个对象版本、5 个删除标记，约 600 MB 数据，覆盖 multipart、gzip、特殊 key、版本链、对象锁、生命周期、策略和 IAM。对象内容逐个比对 SHA-256，不是看见 HTTP 200 就算过。

MinIO 源和 Silo 源结果一致，三个官方构建结果一致。IAM 的用户、策略、组、服务账号原样导入。

最让我意外的是回滚。我一直觉得 drop-in 最要紧的不是怎么进去，是出了问题能不能退出来。老数据读得出来不算完，你在新软件上写了一批数据，发现不合适，换回去还认不认？这一轮他们做到了：换到 RustFS，写新对象，再把二进制换回 MinIO，全部读得出，SHA-256 全对。

迁移的边界条件

这轮也摸到三个边界，应该明确写出来。

第一，不能滚动替换。 四节点里换一个，3+1 混跑；换两个，2+2 混跑，RustFS 节点一律报 erasure read quorum，读不出测试对象。到了 2+2，剩下两个 MinIO 节点也写不进去了，整个集群丢了写仲裁。所以“换个二进制就能迁移”的图景里，得补上两个字：停机。 全停、全换、再起，可以；一台一台换、指望新旧混跑过渡，不行。好在这通常是能接受的代价。

第二，加密数据过不去。 开了 KMS 的集群，RustFS 导入 IAM 配置时直接退出，给同一把主密钥也起不来。不走 KMS 的 SSE-C，RustFS 能起，但给对密钥也读不了 MinIO 的 sealed 格式，报错指向一个叫 rio-v2 的 feature，三个官方构建都没启用它。反向也不通：RustFS 新写的 SSE-C 对象，回滚到 MinIO 报 XMinioObjectTampered。所以上面那张全绿的表，不包括加密数据。

第三，启动配置不能照搬。 MINIO_ROOT_USER、MINIO_ROOT_PASSWORD 这套环境变量能用，拿原凭据登录，五个桶都在。但 unit 文件里只要带着 --certs-dir，RustFS 解析参数就退出。上了 TLS 的生产环境基本都有这个参数，证书怎么配、原来的安全边界怎么保持，得按 RustFS 的方式重新核对一遍。

所以官方那句“MinIO 用户可以直接通过二进制替换完成迁移”，旁边至少该写上三个前提：未加密、全停替换、调整启动配置。 写清楚，这句话成立，而且了不起；不写清楚，就是半夜三点的惊喜。

掉两个节点，还能不能读？

这轮还测出一个行为差异，值得单独说。MinIO 的读只看数据够不够，RustFS 的读还要看法定人数够不够。四节点各一盘（4N1D）的部署里挂掉两个节点，MinIO 降级成只读，RustFS 直接变砖。这大概是迁过去之后最大的惊讶，平时看不出区别，掉节点的时候才知道。对备份存储来说，这就是最坏的时候能不能把备份拿出来的差别。这未必是 Bug，也可能是有意的设计，但至少该写进迁移文档。

我测的范围也说清楚：单个 erasure set，同机四进程，静态样本。真实多机多 pool、网络分区、修复重建、长期负载、外部 KES、复制分层、S3 Tables，都没测。结论只对这个版本、这个样本、这个拓扑负责。

兼容做到这儿，够了，别往下追了。 加密兼容要追的是 MinIO 的 sealed format 和密钥封装，滚动替换要追的是它的节点间协议。再往下做，很容易变成 MinIO 改什么你补什么，等于给自己戴上 MinIO 的镣铐。

存量里没加密、能停机的那部分，RustFS 现在就接得住；有加密、停不了机的那部分，可以继续评估 Silo 这类兼容路线，也可以走 S3 接口另行规划迁移，不必把所有历史包袱都压给一个重写项目。RustFS 该做的是 RustFS 自己。

RustFS 自己的功课

兼容的账算完了。下面两条跟 MinIO 的格式、协议都没关系，是 RustFS 自己的事。

监控这件事得补上

这个问题我私下提过。RustFS 的指标走 OTel 推送，没有 Prometheus 兼容的 /metrics 端点。文凯给的方案是让 Prometheus 开 --web.enable-otlp-receiver 直接收。能接上，但离“把生产监控解决了”还有距离。

严肃场景里 Prometheus 从来不是一个，至少两副本，各自独立抓取、独立核验——抓取成没成，本身就是最重要的健康信号之一。推送模型意味着你只能推给一个，要推给两三个就得在中间架一层扇出，链路断了算谁的？这不是 RustFS 的锅，是推拉两种模型的根本差异。但对运维侧是真实的卡点：用着 Prometheus、VictoriaMetrics 的团队，只是想加一个对象存储，不想顺便改造一次监控架构。

再挑剔一句。功能表里 S3、WebDAV、Swift、FTP、SFTP、MCP 六种协议都有，偏偏少了一个 /metrics。宽和深是两回事。Swift API 一年未必碰得上一次，指标、告警、巡检天天都要用。MinIO 很早就把这个端点做好了，这是它能长进云原生那套东西里的原因之一。RustFS 要接它的班，这一课值得尽早补。

1.0 该交出来的，不只是功能清单

几个月前我问文凯什么时候去掉 Alpha。他说，还有几个 Bug 没解决好，不敢 GA。这个回答我挺喜欢——存储软件的 1.0，就该是“不敢”出来的。

现在 1.0 GA 发了，官方说“核心对象存储能力已经足够稳定”。上面那轮替换测试，算我替他们验了一小块。我没测的那些，才是 1.0 真正该交出来的：真实多机多 pool，网络分区，节点损坏后的修复重建，长期负载，外部 KMS，站点复制和分层。这些每一项都是对象存储在生产上出事的地方。各测了什么、怎么测的、结果如何、还有哪些已知限制，最好公开。我没测过，不代表团队没测过；但用户看不见，就没法据此判断。

对象存储的麻烦就在这里：平时存取正常，很容易让人觉得“已经挺稳了”；真正的考验，是坏盘、断网、重建、扩容撞在一起的时候。等用户替你碰上了再解释版本号是什么意思，就晚了。

真正要盯住的是商业化

前面都是技术问题，能修，能补，能接着测。下面这个问题，我更在意。官方稿子的后半段讲了 2.0 路线图：以 AI 为中心，DPU 加速数据路径，RDMA，S3 Vector，“让 GPU 持续获得充足的数据”。

方向没什么问题。但看到这里，很难不想起另一份稿子。这个故事 MinIO 已经讲了两年：AIStor、RDMA、GPUDirect、Tables，卖的也是“AI 数据中心的数据底座”。RustFS 2.0 讲同一个故事，用户凭什么再换一次？

性能、功能、价格当然都能争。但对我来说，最有分量的区别，是它能不能长期保持开源，并且让开源版一直值得用。

文凯跟我说，目前开源版和商业版还没有分，GA 之后会开始做功能区分。公司要挣钱，完全合理。要盯住的是边界怎么划，划完以后会不会一直往回收。

MinIO 的路是怎么走的，值得摆在这里对照一下。它最早也是 Apache 2.0，靠这个许可证攒下了最初那批用户和生态。2021 年改成 AGPL。2024 年 3 月发布 Enterprise Object Store，商业版第一次做成单独的二进制。之后的事大家都看见了：控制台功能删减，停发部分发行物，开源仓库进入维护模式，直到这次 Docker Hub 仓库消失。

改一次许可证，单独做一个商业版，都不能说从那天起后面的事就注定了。但每一步都往回收一点，几年下来，用户才发现熟悉的东西所剩无几。MinIO 每一次做减法都是悄悄的，用户自己踩了坑才发现。

Apache 2.0 能保住的，是已经按这个许可证发出去的代码。它保不了下一版代码还公开，保不了许可证不会改，也保不了有人继续给你打包、发镜像、维护文档。MinIO 留下的教训恰恰是：代码一直都在，但人家直接搞供应链断供，上屋抽梯，用户照样被折腾得够呛。RustFS 今天的 Apache 2.0 许可，MinIO 当年也有过。

RustFS 最大的风险，不是做不成 MinIO，是做成了 MinIO。

所以我的建议就一条：把边界写下来。 哪些能力留在开源版，哪些属于企业版；许可证会不会改，改了以后老版本怎么算；二进制、镜像、历史版本在哪发、保留多久；如果有一天公司不维护了，用户和社区能接走什么。写成公开文档，标上日期，以后有变化也公开说明。

S3 Tables“完全开源”已经是个好开头。接下来要让用户知道，这是一项孤立的决定，还是整个产品会遵循的原则。公开承诺不是万能保险，但总比让用户到处翻 Issue、猜下一次更新会拿走什么强。MinIO 从来没写过这样一份东西，这就是 RustFS 能跟它拉开的第一个距离。

别活成 MinIO 的样子

官方稿子里有一节叫“RustFS，不是另外一个 MinIO”。我愿意信，也想把这句话说得更具体一点。

第一，别把 MinIO 的过去当终点。磁盘格式兼容接住了一批用户够了。MinIO 开源版的功能集，是一家公司在商业压力下砍剩下的东西，追平它最多算拿到入场券，不该是长期目标。

第二，别照着 MinIO 的现在再走一遍。AI、DPU、RDMA 都可以做，但一边讲新故事、一边从开源版往回收东西，这套玩法大家刚经历过。换成 Rust 写，不能让用户忘掉上一回。

那该盯着谁？盯着 S3 生态和用户接下来需要什么。S3 已经是对象存储的事实标准，但标准的解释权在 AWS 手里，本地部署这边，得有人拿开源的方式跟住它。Tables、Vectors、Express，挑有价值的做，做出来就放在开源版里。这条路 MinIO 走了一半就跑路了，而这就是 RustFS 的机会。S3 Tables 已经迈出一步，后面怎么走，比发布稿怎么写重要。

最后

我当初跟文凯说过：什么时候去掉 Alpha，我就想办法把 MinIO 换掉。今天到了 1.0，这话还算数。不过真要往生产里换，上面那些问题还得有答案。我会在 Pigsty 中添加 RustFS 的替换引擎选项，但能不能作为默认选项，还有待时间进一步证明。朋友归朋友，数据安全可不是拿来捧场的。

作为竞争对手，我希望 RustFS 把增量那一半做扎实，这样存量那一半我能安心做；作为校友，我希望它别走弯路；作为给它打包的人，我希望明年这时候，它已经扛起开源对象存储的大旗，成为对象存储世界替代 MinIO 的默认选项。

祝 1.0 顺利。

盯着 MinIO 打，别打成 MinIO。