# RustFS 1.0 GA：别活成 MinIO 的样子

LLMS 索引： [llms.txt](/llms.txt)

---

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

动笔之前，先把利益关系交代清楚。老冯呢，维护着一个 PostgreSQL 发行版 Pigsty，里面用到了 MinIO 作为对象存储。之前 [MinIO 跑路](/db/minio-resurrect/)，所以我自己维护着一个 Fork——[Silo](/db/long-live-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`，有人干脆换掉。

![Docker Hub 上的 minio/minio 仓库页面返回 404](dockerhub-404.webp)

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、能源、金融、云计算行业都有了付费客户。

![RustFS 从 2024 年 2 月写下第一行代码，到 2026 年 9 月发布 1.0 GA 的成长时间线](rustfs-timeline.webp)

数字挺漂亮，不过拉取量得放在一起看：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 开源版本”，单看清单不算离谱。至于每一个“支持”能支持到什么程度，得逐项验。

![RustFS 核心功能一览：数据管理、多协议接入、安全审计、可靠性与可维护性](rustfs-features.webp)

**最后一条，也是我这次最想夸的：对 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 |
| -------------- | ------------ | ------ | ------------ |
| 单机单盘       | 125/125      | 25/25  | 150/150      |
| 单机四盘       | 125/125      | 25/25  | 150/150      |
| 四节点全停替换 | 125/125      | 25/25  | 153/153      |

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

![替换二进制并重启 RustFS 后，登录验证桶和对象数据完整迁移](drop-in-migration.webp)

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

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

![四节点挂两节点的读行为对比：MinIO 降级为只读，RustFS 直接不可读](quorum-test.webp)

我测的范围也说清楚：单个 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。**