MinIO 归档之后：LibreFS 与 RustFS 两条开源路线的真实对比-育师

一句话定位：RustFS 是面向 AI 时代、从零原生打造的高性能分布式对象存储，100% 兼容 S3 API，Apache 2.0 协议，底层用 Rust 构建，可作为 MinIO 的 drop-in 替代方案。

1. 问题背景：MinIO 归档后去哪

MinIO 在 2025 年底把开源仓库归档、进入维护模式之后，一大批原本跑社区版 MinIO 的团队开始重新看替代方案。需求其实分两类：一类是想继续用 MinIO 那一套，只是希望它重新开源、别断更；另一类是想借这个契机换一条更顺手的路线。

社区里应运出现了两条开源路线：一条是LibreFS——社区驱动的 MinIO fork，主打"把 MinIO 重新开源"；另一条是RustFS——用 Rust 从零重写、Apache 2.0 的对象存储。两者都还年轻，但走的路完全不同。

2. 两条路线的出身

LibreFS：本质是 MinIO 的社区 fork，沿用 MinIO 的代码基与生态。它的卖点很直接——你熟悉的 MinIO 工具链、文档、社区问答基本都能复用，只是换了个还在活跃维护的源头。它的基准测试里，大文件写入能到 28.8 MB/s（对照 MinIO 约 20.2 MB/s），在流式处理场景下的稳定性也和 MinIO 接近。
RustFS：不是 fork，是用 Rust 从零写的高性能分布式对象存储，100% 兼容 S3 API。它不背 MinIO 的历史包袱，换来的是 Apache 2.0 的协议自由和 Rust 的内存安全。

选哪条，先看清几个维度的差异，而不是只看"是不是 MinIO 的延续"。

3. 许可证：最根本的分叉

这是两条路线分道扬镳的地方，也最影响"能不能用"：

LibreFS沿用了 MinIO 的AGPLv3。对纯内部自用、不对外提供网络服务、不改代码的情况没问题；但一旦要把存储嵌进闭源产品或对外提供商业服务，AGPL 的 copyleft 就会触发源码公开义务。
RustFS是Apache 2.0。没有 copyleft，没有源码公开义务，做闭源集成、二次开发、私有部署都没有协议层面的法律摩擦。

如果你正评估"把对象存储做成产品的一部分对外卖"，许可证这一项基本就替你做了决定。RustFS 的 Apache 2.0 在这里是实打实的优势。

4. 语言与内存安全：Rust 带来的硬差异

对象存储是长驻进程，两类故障最隐蔽：内存错误和 GC 停顿。

LibreFS 跟随 MinIO 走Go，好处是生态成熟、并发模型好写；代价是高负载下 Go 的GC 停顿不可完全预测——写密集型场景里，一次 GC 可能让 checkpoint 写入超时重试。
RustFS 用Rust，在编译期就堵住一大类内存安全问题，运行期没有 GC 停顿。长驻进程里，同样负载下内存抖动更小，OOM kill 概率更低。

这不是"谁更好"的玄学判断，是两种运行时模型的直接后果。对一个 7×24 跑的对象存储底座，GC 停顿和内存安全是会被半夜告警放大的事。

5. 性能与成熟度：各自的边界

把性能说清楚，也给边界：

维度	LibreFS	RustFS
大文件写入（一次社区基准）	28.8 MB/s	各有领先区间
小对象写入	基准中落后	领先明显（4KB 约 2.3× MinIO）
生态成熟度	沿用 MinIO 生态，问答多	快速发展中，文档/集成在补齐
稳定性定位	流式处理接近 MinIO	团队把高强度流式稳定性列为当前头等工程重点

RustFS 在小对象写入上优势明确：官方同机对比里，4KB 对象的 PUT 吞吐大约是 MinIO 的 2.3 倍；beta.10 基准里 PUT 在全尺寸领先，4MiB 达到 2.85×。但也要把读负载的边界算进去——在 100KiB–1MiB 这段，RustFS 的 GET 目前仍落后 MinIO（beta.10 里 1MiB 约为 0.23×），读密集且踩在这个区间的负载，选型时要单独比一轮。

至于成熟度，LibreFS 借 MinIO 的家底，文档和社区答案更多；RustFS 年轻但迭代快，官方把"高强度流式负载下的稳定性与一致性"明确列为 GA 前的头等工程重点，正在持续投入。两者都不该被简单贴上"稳/不稳"的标签——具体落到你的负载画像上才有意义。