答案是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 占用最高的目录
避免全盘扫描，聚焦高风险路径并逐级排查：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 对 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%。
