如何解决因磁盘 Inode 节点耗尽导致的镜像无法创建故障

答案是inode耗尽，因每个文件、目录均占用一个inode，海量小文件（如日志、Docker镜像层）会快速耗尽有限inode，即使df -h显示磁盘空间充足；可通过df -i确认IUse%达100%且对应分区空间使用率远低于100%来验证，重点检查/var/lib/docker等路径。

镜像无法创建却提示“No space left on device”，而磁盘空间（df -h）显示充足，大概率是 inode 耗尽所致。这不是存储空间不够，而是文件系统能管理的文件数量上限用完了——每个文件、目录、socket 都要占用一个 inode，海量小文件（如缓存、日志、临时会话）极易快速填满它。

确认是否为 inode 耗尽

执行以下命令验证：

• df -i：查看各挂载点的 inode 使用率，重点关注 IUse% 列；若达 100% 或接近（如 98%），且对应分区的 df -h 空间使用率远低于 100%（例如仅 30%），即可确认是 inode 耗尽。
• 特别注意 Docker 场景：运行 df -i /var/lib/docker，这是最常见故障点。

定位 inode 占用最高的目录

避免全盘扫描，聚焦高风险路径并逐级排查：

• 对 Docker 数据目录快速统计：find /var/lib/docker -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -15
• 常见重灾区包括：
    • /var/lib/docker/overlay2（已删除但未清理的镜像层）
    • /var/lib/docker/tmp（构建过程残留临时文件）
    • /var/log/journal（未轮转的 systemd 日志）
    • /tmp 或 /var/tmp（长期未清理的临时文件）
• 进入可疑目录后，用 ls -A | wc -l 查当前文件总数，或 du --inodes -sh * 按 inode 数量排序子项。

安全清理释放 inode

清理需兼顾有效性与服务稳定性，避免误删运行中文件：

• Docker 自动清理（推荐优先执行）：
  docker system prune -f（清理停止容器、悬空镜像、未使用网络）
  若需更彻底：docker system prune -a -f --volumes（慎用，会删未使用的卷）
• 手动精准清理：
  • 清理 overlay2 中无引用的层：docker builder prune -f 或 docker image prune -a -f
  • 清理旧日志：journalctl --vacuum-time=7d
  • 清理临时目录：find /tmp -type f -mmin +1440 -delete（删除 24 小时前的普通文件）
• 切勿直接 rm -rf /var/lib/docker/* 或 rm -rf /tmp —— 可能中断正在运行的容器或系统服务。

预防再次发生

一次性清理只能治标，需建立长效防护机制：

• 为 Docker 配置磁盘配额（如通过 daemon.json 设置 storage-driver: overlay2 并启用 overlay2.size 限制）
• 设置定期清理任务：
  0 2 * * * docker system prune -f > /dev/null 2>&1（每日凌晨清理）
  0 3 * * * journalctl --vacuum-time=3d > /dev/null 2>&1
• 监控告警：在运维平台（如 Prometheus + Node Exporter）中添加 node_filesystem_files_free{mountpoint="/var/lib/docker"} 告警规则，阈值设为 5%。