宿主机 inode 耗尽会导致容器日志写入失败，本质是文件系统无法分配新元数据节点；需用 df -i 确认 /var 等分区 iuse% ≥ 95%，再定位 /var/lib/docker/overlay2 或 /var/spool/postfix/maildrop 等高 inode 占用目录，清理后结合日志限制、logrotate 和监控预防复发。
宿主机 inode 耗尽会导致容器日志写入失败——不是日志驱动或应用配置问题，而是文件系统已失去创建新日志文件的能力。即使磁盘空间充足，docker logs 可能为空、touch 报 no space left on device、容器内 echo "x" > /tmp/test.log 失败，本质是 inode 池满，无法分配新元数据节点。
第一步：确认是否真为 inode 耗尽
别只看 df -h，必须运行：
-
df -i—— 重点检查/var、/var/lib/docker、/tmp所在挂载点的IUse%是否达 95%+（尤其是 100%） - 若
/var分区 IUse% = 100%，而df -h /var显示还有数 GB 空间，即可确诊 - 注意：Docker 日志默认存于
/var/lib/docker/containers/<id>/<id>-json.log</id></id>，该路径归属/var分区，其 inode 独立计算
第二步：快速定位 inode 占用大户
聚焦高风险目录，避免全盘扫描：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 查邮件队列：
find /var/spool/postfix/maildrop -type f 2>/dev/null | wc -l（常达数十万小文件） - 查 Docker 临时残留：
find /var/lib/docker/overlay2 -maxdepth 2 -type d -name "diff" | xargs -r ls -d 2>/dev/null | wc -l - 查日志碎片：
du --inodes -sh /var/log/* 2>/dev/null | sort -hr | head -5 - 查 tmp 下零字节文件：
find /tmp -xdev -type f -size 0 -mtime +3 2>/dev/null | head -20（先预览再删）
第三步：安全清理并释放 inode
删文件 ≠ 释放 inode，需确保无进程占用：
- 清空已确认废弃的目录（如停用的 postfix 队列）：
rm -f /var/spool/postfix/maildrop/*（进目录后执行，防路径错误） - 批量删旧日志：
find /var/log -name "*.log.*" -mtime +7 -print0 | xargs -0 rm -f - 清理 Docker 未使用资源（谨慎）：
docker system prune -f --volumes（会删停止容器的卷和构建缓存） - 检查“已删但未释放”文件：
lsof +L1 | grep -E "(json\.log|maildrop)"，若有输出，重启对应服务（如systemctl restart docker）
第四步：防止复发——从日志和容器层面加固
光清理治标，必须切断高频小文件生成链路：
- 为所有生产容器强制加日志限制：
--log-driver=json-file --log-opt max-size=10m --log-opt max-file=3 - 禁用应用调试日志：检查容器内
process.env.DEBUG（Node.js）、logging.getLogger().level（Python）、JVM 启动参数中的-Dlogging.level.root=DEBUG - 对
/var/log和/tmp启用 logrotate，并确保配置含create指令，避免轮转后缺 inode 创建新文件 - 监控落地：
df -i加入 Prometheus Node Exporter 或 Zabbix，IUse% ≥ 85% 即告警
