记一次 minio 排障

问题现象:

中午接到开发反馈,生产上无法上传附件。接口显示 minio 问题,超时,无法访问

  • minio 控制台 也登录不上

  • 查看 minio 服务报错:

    journalctl -u minio.service --since today

  • 发现大批量报错:

    API: PutObject
    Time: 03:01:53 UTC 12/15/2025
    DeploymentID: 944869e6-7044-4c56-a3bf-64d00fa843cc
    RequestID: 188144605A9808E1
    RemoteHost: 192.168.3.111
    UserAgent: MinIO (Linux; amd64) minio-java/8.5.7

    Error: drive:/home/application/Middleware/minio/data, srcVolume: .minio.sys/tmp, srcPath: c6ce506f-87c0-453f-a9e2-b6245c05171e, dstVolume: srebro:, dstPath: 53ba5209-8843-4df1-b41d-b5b798cd6080 - error drive path full (*errors.errorString)

    Backtrace:
    0: internal/logger/logonce.go:118:logger.(*logOnceType).logOnceIf()
    1: internal/logger/logonce.go:149:logger.LogOnceIf()
    2: cmd/logging.go:142:cmd.storageLogOnceIf()
    3: cmd/xl-storage.go:2469:cmd.(*xlStorage).RenameData.func1()
    4: cmd/xl-storage.go:2768:cmd.(*xlStorage).RenameData()
    5: cmd/xl-storage-disk-id-check.go:484:cmd.(*xlStorageDiskIDCheck).RenameData.func2()
    6: internal/ioutil/ioutil.go:116:ioutil.WithDeadline[...].func1()

  • 翻阅资料,查看到官方的代码仓库上有一个 issue 相识:https://github.com/minio/minio/issues/17055

有人反馈说是,ext4 文件系统,目录的索引(HTree)已达到默认的最大层级;

  • 继续查看系统级别日志,发现果然 文件系统一直在报错:

    Dec 15 03:22:22 localhost kernel: [20102682.954029] EXT4-fs warning (device dm-2): ext4_dx_add_entry:2451: Large directory feature is not enabled on this filesystem

    Dec 15 03:22:24 localhost kernel: [20102682.954029] EXT4-fs warning (device dm-2): ext4_dx_add_entry:2451: Large directory feature is not enabled on this filesystem

    Dec 15 03:22:26 localhost kernel: [20102682.954029] EXT4-fs warning (device dm-2): ext4_dx_add_entry:2451: Large directory feature is not enabled on this filesystem

    Dec 15 03:22:28 localhost kernel: [20102682.954029] EXT4-fs warning (device dm-2): ext4_dx_add_entry:2451: Large directory feature is not enabled on this filesystem

  • 问题分析:

    • 这是内核的 EXT4 警告,表示某个目录的索引(HTree)已达到默认的最大层级,继续插入新目录项需要启用 EXT4 的"大目录"特性( large_dir ),但当前文件系统未启用该特性。

    • 典型触发场景是"单个目录下存在超大量文件/子目录"(千万级以上),插入新文件时会出现"Directory index full"和"Large directory feature is not enabled"这两条警告连续出现。

处理方式:

  • 停用 minio 服务

    systemctl stop minio

  • 启用大目录特性

    tune2fs -O large_dir /dev/dm-2

  • 启用 large_dir 可以解决"目录索引达到最大层级(htree level 2)"导致的警告和后续插入失败/变慢问题;启用后目录支持更高层级索引,能继续容纳超大数量的目录项。

  • 启动 minio 服务

    systemctl start minio

  • 观察日志是否还有报错

    journalctl -k --since '-10 min' | grep -E 'ext4_dx_add_entry|Large directory'

思考:

  • 出现这个问题,本质是 minio 数据目录下,单个目录下存在超大量文件/子目录"(千万级以上),业务上没有做分桶,分区的处理;数据文件没有设置生命周期归档处理;导致数据量一直在增长,数据量达到了 3.7T,文件 13395087个。

  • 运维侧,在初始化项目的时候,没有考虑到 xfs 系统 和 ext4 系统在 目录索引这块的差别;

    • XFS :目录使用 B+tree,天然支持多层索引,默认就能高效处理超大目录。
    • ext4 :目录使用 HTree 索引,默认是"两层 HTree"(特性为 dir_index ),单目录通常能容纳约 10--12 百万个条目;达到两层上限后会出现 "Directory index full / Large directory feature is not enabled" 警告。
  • 完善 minio 监控这块的不足,发现问题能及时通知响应处理。官方文档(https://min-io.cn/docs/minio/kubernetes/upstream/operations/monitoring.html)

相关推荐
分布式存储与RustFS10 小时前
Longhorn 的卷备份别堆本地盘:用 RustFS 给它当 S3 备份目标
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
分布式存储与RustFS1 天前
JuiceFS 接 RustFS 当数据后端:把对象存储挂成本地文件系统
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
分布式存储与RustFS1 天前
K8s 集群备份落到自建对象存储:Velero 接 RustFS 配置指南
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
分布式存储与RustFS2 天前
可观测性数据落进对象存储:Proscia 案例拆解与 ClickHouse 自托管配置
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
分布式存储与RustFS2 天前
Kafka 分层存储落地指南:冷 Segment 自动落到 RustFS 对象存储
运维·云原生·开源·对象存储·分布式存储·s3·性能基准
分布式存储与RustFS5 天前
CI 老被 Docker Hub 的 429 卡住,自建 Registry 把镜像搬进内网
运维·docker·开源·镜像仓库·对象存储·ci·rustfs
分布式存储与RustFS6 天前
模型权重散落在每台 GPU?用 RustFS 给 vLLM 做共享权重库
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准
寰梦6 天前
Spring Boot + MinIO 大文件上传完整实战:MD5 秒传、分片上传、断点续传与引用一致性
java·spring boot·文件上传·minio
分布式存储与RustFS7 天前
你的网站备份只存一块盘?把 1Panel 的备份目标换成 RustFS
运维·开源·备份·对象存储·1panel·s3·rustfs
分布式存储与RustFS7 天前
十分钟在自己机器上跑通一个 S3 兼容对象存储(RustFS + Docker)
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准