MinIO 已死，MinIO 永存一、新闻概述1. 标题MinIO 已死，MinIO 永存2. 发布时间2026 年 2 月 14 日3. 来源Vonng 博客二、核心内容1. 事件摘要A. 主要内容MinIO 的开源仓库已被官方正式归档，不再维护。一个时代的终结，但开源项目不会轻易消亡。B. 核心亮点MinIO 官方仓库已正式归档，只读状态作者创建了 MinIO 分支，恢复管理控制台重建二进制分发管道，让项目重获新生修复 CVE 漏洞2. 关键信息A. 版本号/发布内容pgsty/minio 分支，版本号 RELEASE.2026-02-14T12-00-00ZB. 重要数据原项目获得 6 万星标Docker 拉取量超过 10 亿次官方融资 1.26 亿美元，估值 10 亿美元C. 涉及产品MinIO 对象存储、pgsty/minio 分支3. 背景介绍A. 前置版本2025 年 12 月 3 日，MinIO 宣布进入维护模式，作者已撰文分析。B. 相关上下文从 Apache 2.0 协议到 AGPLv3 协议，从开源宠儿到商业软件公司，MinIO 走过了五年的转型之路。三、详细报道1. 主要内容A. 官方归档2026 年 2 月 12 日，MinIO 将仓库状态从维护模式更新为不再维护，随后正式归档仓库。只读状态，不再接受 PR、Issue 和贡献。B. 时间线分析回顾过去几年的发展历程，这并非突然死亡，而是一个缓慢、刻意的收缩过程：时间事件性质2021-05Apache 2.0 → AGPL v3 协议变更许可证变更2022-07起诉 Nutanix许可证执行2023-03起诉 Weka许可证执行2025-05从社区版移除管理控制台功能限制2025-10停止二进制/Docker 分发供应链切断2025-12宣布维护模式生命周期结束信号2026-02仓库归档，不再维护项目终结C. 行业反应Percona 创始人 Peter Zaitsev 在 LinkedIn 上对开源基础设施可持续性提出担忧。国际社区共识明确：MinIO 已结束。2. 技术细节A. 分支恢复工作作者完成的恢复工作包括：graph TB A[MinIO 官方归档] --> B[创建 pgsty/minio 分支] B --> C[恢复管理控制台] B --> D[重建二进制分发] B --> E[恢复社区版文档] C --> F[用户管理] C --> G[存储桶策略] C --> H[访问控制] D --> I[Docker 镜像] D --> J[RPM/DEB 包] D --> K[CI/CD 管道] E --> L[修复损坏链接] E --> M[恢复控制台文档] E --> N[部署到 silo.pigsty.io]B. 管理控制台恢复2025 年 5 月，MinIO 从社区版移除了完整的管理控制台，只保留了基础的对象浏览器。用户管理、存储桶策略、访问控制、生命周期管理等功能一夜之间消失。恢复工作仅需回退 minio/console 子模块到之前版本。他们通过更改依赖版本将完整控制台替换为简化版本，代码一直都在那里。C. 二进制分发重建2025 年 10 月，MinIO 停止分发预构建二进制文件和 Docker 镜像，只保留源代码。对于绝大多数用户来说，开源软件的价值不仅仅是源代码副本，供应链的稳定性才是关键。用户需要的是一个可以放入 Dockerfile、Ansible 剧本或 CI/CD 流水线的稳定产物，而不是在每次部署前都必须安装 Go 编译器的要求。D. 文档恢复MinIO 官方文档也面临风险，链接开始重定向到他们的商业产品 AIStor。作者 fork 了 minio/docs 仓库，修复了损坏的链接，恢复了被移除的控制台文档，并部署到独立站点。3. 技术承诺A. 不增加新功能，仅保证供应链连续性MinIO 作为 S3 兼容的对象存储已经功能完整。它是一个成熟的软件，不需要更多花哨的功能，它需要的是一个稳定、可靠、持续可用的构建。B. 这是生产构建，不是归档作者在自己的环境中运行这些构建，已经在生产环境试用了三个月。如果出现问题，可以早期发现并快速修复。C. 愿意追踪 CVE 和修复漏洞如果遇到问题，可以在 pgsty/minio 项目报告。作者会尽力修复，但请不要将其视为商业 SLA。D. 商标问题AGPLv3 赋予了明确的 Fork 和分发权利，但商标法是另一个领域。作者已在各处明确标记这是独立社区维护的构建。如果 MinIO 公司提出商标问题，会配合改名，可能是 silo 或 stow 之类的名称。四、影响分析1. 行业影响A. 开源可持续性MinIO 从开源宠儿到警示故事的过程，引发了业界对开源项目商业化和可持续性的讨论。B. 分支生态的兴起HashiCorp 的 Terraform 被分支为 OpenTofu，发展良好。MinIO 的情况实际上更有利，AGPL 对分支的许可比 BSL 更宽松，社区分支没有法律灰色地带。2. 用户影响A. 现有用户对于使用 MinIO 的用户，只需将 minio/minio 替换为 pgsty/minio，其他一切保持不变。B. 潜在用户新的社区分支提供了与原项目兼容的选择，避免了迁移到其他对象存储的成本。C. 迁移建议使用 Docker 的用户，只需替换镜像名称。原生 Linux 安装可以从 GitHub Release 页面获取 RPM/DEB 包。五、技术趋势A. AI 改变游戏规则AI 编码工具正在改变开源维护的经济性。使用 Claude Code 和 Codex 等工具，在复杂的 Go 项目中定位和修复漏洞的成本已经下降了一个数量级。B. 一个人维护的可行性以前需要一个专门团队来维护的复杂基础设施项目，现在可以由一位经验丰富的工程师配合 AI 副驾驶来处理。C. 测试和验证维护 MinIO 构建而不添加新功能是一项可控的任务。关键要求是测试和验证，而作者已有测试场景，可以在实践中验证兼容性、可靠性和安全性。六、各方反应1. 作者立场开源许可证的设计初衷就是让代码不会消亡。Fork 是开源中最强大的法术。当一家公司决定关上大门时，社区只需要两个词：Fork it。2. 社区反馈MinIO 公司可以归档 GitHub 仓库，但他们无法归档 6 万星标背后的需求，也无法归档 10 亿次 Docker 拉取背后的依赖图。这种需求不会消失，只会找到出路。七、相关链接1. 官方公告MinIO Is Dead 原文分析MinIO Is Dead, Are There Alternatives? 替代方案分析2. 技术资源pgsty/minio 仓库pgsty/minio-docs 文档站点Pigsty 项目主页3. 安装方式Docker 安装：docker pull pgsty/minio使用 pig 包管理器安装：curl https://repo.pigsty.io/pig | bash pig repo add infra -u pig install minio参考资料MinIO Is Dead, Long Live MinIO
JuiceFS 云原生分布式文件系统技术分析一、新闻概述1. 标题JuiceFS：基于 Redis 和 S3 构建的高性能云原生分布式文件系统2. 发布时间2024 年3. 来源JuiceFS 官方 GitHub 仓库二、核心内容1. 事件摘要A. 主要内容JuiceFS 是一个采用 Apache License 2.0 开源协议的高性能 POSIX 文件系统，专为云原生环境设计。B. 核心亮点完全兼容 POSIX 标准，无需修改现有应用代码数据与元数据分离架构，数据存储在对象存储，元数据存储在 Redis 等数据库强一致性保证，文件修改立即在所有挂载点可见云原生设计，提供 Kubernetes CSI Driver出色的性能表现，吞吐量可比传统方案提升 10 倍2. 关键信息A. 技术架构数据存储层：支持 S3、GCS、Azure Blob、阿里云 OSS 等多种对象存储元数据引擎：支持 Redis、MySQL、SQLite、TiKV 等多种数据库客户端层：实现 POSIX、Hadoop、Kubernetes、S3 Gateway 等多种接口B. 性能指标延迟：可低至毫秒级吞吐量：近乎无限扩展（取决于对象存储规模）元数据 IOPS：显著高于 EFS 和 S3FS 等竞品通过 8813 项 pjdfstest 兼容性测试C. 应用场景大数据分析平台机器学习与人工智能容器化环境（Kubernetes）Hadoop 生态系统三、详细报道1. 架构设计A. 系统组成JuiceFS 采用数据与元数据分离的架构设计，由三个核心部分组成：JuiceFS 客户端：协调对象存储和元数据存储引擎，实现 POSIX、Hadoop、Kubernetes、S3 Gateway 等文件系统接口数据存储：存储实际数据，支持本地磁盘、公有云或私有云对象存储、HDFS 等多种存储介质元数据引擎：存储文件名、文件大小、权限组、创建和修改时间、目录结构等元数据信息graph TB subgraph 客户端层 A1[POSIX 客户端] A2[Hadoop SDK] A3[Kubernetes CSI] A4[S3 Gateway] end subgraph JuiceFS 架构 B1[JuiceFS 客户端] B2[数据存储] B3[元数据引擎] end subgraph 存储层 C1[对象存储 S3/GCS/Azure] C2[Redis/MySQL/TiKV] end A1 --> B1 A2 --> B1 A3 --> B1 A4 --> B1 B1 --> B2 B1 --> B3 B2 --> C1 B3 --> C2B. 数据存储结构JuiceFS 采用分层的数据存储结构，将文件切分为固定大小的单元进行存储：Chunk：文件的最大切分单元，默认上限为 64 MiBSlice：由一个或多个 Slice 组成，长度根据写入方式变化Block：Slice 的组成单元，固定大小为 4 MiBgraph LR A[源文件] --> B[Chunk 64MiB] B --> C[Slice 1] B --> D[Slice 2] C --> E[Block 4MiB] C --> F[Block 4MiB] D --> G[Block 4MiB] E --> H[对象存储] F --> H G --> H2. 核心特性A. POSIX 兼容性JuiceFS 完全兼容 POSIX 标准，通过了 pjdfstest 的全部 8813 项测试。除标准 POSIX 特性外，还提供：Close-to-open 一致性：文件写入并关闭后，保证所有客户端的后续打开和读取操作都能看到写入的数据原子性操作：重命名和其他元数据操作具有原子性，由元数据引擎事务保证文件删除后仍可访问：同一挂载点内，已打开的文件在删除后仍可访问内存映射支持：通过 FSx 测试验证预分配支持：支持 punch hole 功能扩展属性：支持 xattr文件锁：支持 BSD 锁和 POSIX 记录锁B. 性能优化JuiceFS 在性能方面表现出色：延迟优化：通过元数据缓存和块数据缓存实现毫秒级访问延迟吞吐量提升：顺序读写吞吐量相比 EFS 和 S3FS 提升约 10 倍元数据性能：元数据 IOPS 显著高于竞品graph LR A[应用] --> B{读取请求} B --> C{检查缓存} C -->|命中| D[返回缓存数据] C -->|未命中| E[访问对象存储] E --> F[更新缓存] F --> DC. 安全性JuiceFS 提供多层次的安全保障：数据加密：支持传输中和静态数据加密全局文件锁：支持 BSD 锁和 POSIX 记录锁数据压缩：支持 LZ4 或 Zstandard 压缩算法3. 应用场景分析A. 云原生环境JuiceFS 提供完整的 Kubernetes CSI Driver，可以轻松在 Kubernetes 中使用：作为 Pod 的持久卷支持动态卷供应与容器编排无缝集成B. 大数据生态JuiceFS 的 Hadoop Java SDK 完全兼容 Hadoop 2.x 和 Hadoop 3.x：无需修改代码即可使用支持 Hadoop 生态系统的各种组件提供与 HDFS 相似的使用体验C. 对象存储网关JuiceFS 提供 S3 Gateway 功能：将对象存储以文件系统方式暴露兼容 S3 API支持多客户端并发访问四、技术细节1. 元数据引擎选择JuiceFS 支持多种元数据引擎，满足不同场景需求：元数据引擎适用场景优势劣势Redis高性能场景低延迟、高吞吐内存成本较高MySQL成本敏感场景成熟稳定、成本低性能相对较低TiKV大规模场景可扩展、强一致性运维复杂度高SQLite单机测试场景部署简单不支持分布式2. 对象存储支持JuiceFS 支持几乎所有主流对象存储服务：Amazon S3 及 S3 兼容存储Google Cloud StorageAzure Blob Storage阿里云对象存储 OSS腾讯云对象存储 COS七牛云对象存储 Kodo青云对象存储 QingStorCeph RGWMinIO本地磁盘3. 客户端接口JuiceFS 提供多种客户端接口：POSIX 客户端：通过 FUSE 挂载为本地文件系统Hadoop Java SDK：用于 Hadoop 生态集成Kubernetes CSI Driver：用于容器编排S3 Gateway：提供 S3 兼容 APIgraph TB A[应用层] --> B[POSIX 接口] A --> C[Hadoop 接口] A --> D[Kubernetes CSI] A --> E[S3 API] B --> F[JuiceFS Client] C --> F D --> F E --> F F --> G[元数据引擎] F --> H[对象存储]五、影响分析1. 行业影响A. 云原生存储趋势JuiceFS 体现了云原生存储的几个重要趋势：存算分离：数据与计算分离，提高资源利用率多云兼容：支持多云环境，避免厂商锁定弹性扩展：根据业务需求动态扩展存储容量B. 开源生态影响JuiceFS 作为开源项目，为云存储领域带来：降低使用门槛：企业可以免费使用和定制促进技术创新：社区驱动快速迭代培养人才：推动分布式文件系统技术普及2. 用户影响A. 现有用户JuiceFS 已在生产环境中被数千台机器使用：存储格式稳定，所有未来版本都将支持活跃的社区支持完善的文档和工具B. 潜在用户对于考虑采用 JuiceFS 的用户：部署简单：快速开始指南可在几分钟内完成部署成本效益：利用对象存储降低存储成本性能优势：相比传统方案有显著性能提升3. 技术趋势A. 与竞品对比特性JuiceFSEFSS3FSPOSIX 兼容性完全兼容完全兼容部分兼容吞吐量高中低元数据 IOPS高中低多云支持是否是成本低高低B. 未来发展方向JuiceFS 的路线图包括：用户和组配额快照功能写一次读多次（WORM）六、使用实践1. 部署方式A. 基础部署# 下载 JuiceFS 客户端 curl -juicefs.com/juicefs # 创建文件系统 juicefs auth \ --token <TOKEN> \ --accesskey <ACCESS_KEY> \ --secretkey <SECRET_KEY> \ <META_URL> \ <NAME> # 挂载文件系统 juicefs mount <NAME> <MOUNT_POINT>B. Kubernetes 部署使用 JuiceFS CSI Driver 在 Kubernetes 中部署：apiVersion: v1 kind: PersistentVolume metadata: name: juicefs-pv spec: capacity: storage: 10Pi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain csi: driver: csi.juicefs.com volumeHandle: juicefs-pv fsType: juicefs2. 性能调优A. 缓存策略JuiceFS 提供多层缓存机制：元数据缓存：减少元数据访问延迟块数据缓存：提高数据读取性能配置选项：可根据场景调整缓存大小和策略B. 网络优化调整并发连接数优化数据块大小选择合适的压缩算法3. 故障排查JuiceFS 提供完善的诊断工具：实时性能监控日志分析故障诊断指南七、社区与生态1. 开源协议JuiceFS 采用 Apache License 2.0 开源协议：允许商业使用允许修改和分发提供专利授权保护2. 社区支持GitHub Discussions：技术讨论和问题交流Slack 频道：实时沟通和支持用户案例分享：生产环境使用经验3. 贡献指南JuiceFS 欢迎社区贡献：代码贡献文档改进问题反馈功能建议参考资料JuiceFS GitHub RepositoryJuiceFS Official Documentation