inode耗尽导致“no space left on device”错误，需先用df -i确认iuse%是否达100%，再用du --inodes定位高消耗目录，检查lsof +l1释放已删未释文件，并针对性清理日志、邮件队列或临时文件。
看到 No space left on device 却发现 df -h 显示磁盘还有几十 GB 空闲？这八成是 inode 耗尽了——它和磁盘空间无关，而是“文件数量上限”被占满。
第一步：确认是不是 inode 问题
直接运行：
df -i
重点看目标挂载点（比如 /var、/tmp 或报错目录所在分区）的 IUse% 列。只要达到 100%，就坐实了 inode 耗尽。注意：各挂载点 inode 池完全独立，/ 分区正常不代表 /var 就安全。
第二步：定位 inode 消耗最多的目录
进入疑似挂载点（如 /var），执行：
du --inodes -s */ 2>/dev/null | sort -nr | head -5
这条命令会列出子目录占用 inode 数量的 Top 5。常见重灾区包括：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
-
/var/log/journal（systemd 日志未轮转） -
/var/spool/postfix/maildrop或/var/spool/mail（邮件队列堆积大量 0 字节文件） -
/tmp或/var/tmp（应用临时文件未清理） -
/var/lib/docker/overlay2（容器层碎片小文件）
找到高值目录后，可继续下钻，例如：du --inodes -s /var/log/journal/* 2>/dev/null | sort -nr | head -3。
第三步：查漏补缺——别忘了“已删未释”的 inode
有时你已经 rm 了大量文件，但 df -i 仍不释放。原因很可能是进程还在打开这些已被删除的文件（即“deleted”状态）。
运行：
lsof +L1 或 lsof | grep deleted
它会列出所有这类“僵尸 inode”及对应进程 PID。处理方式：
- 重启服务：如
systemctl restart rsyslog、systemctl restart docker - 若不能重启，可 kill 进程：
kill -9 <pid></pid>（谨慎操作）
第四步：安全清理与长期预防
确认目录无业务依赖后，按类型清理：
- 清日志：
journalctl --vacuum-size=100M（比直接删/var/log/journal安全） - 删旧临时文件：
find /tmp -type f -mtime +7 -delete - 批量删海量小文件（防参数超长）：
find /path -type f -print0 | xargs -0 -n 1000 rm -f - 禁用无意义输出：
crontab -e中加MAILTO=""，避免邮件队列膨胀
长期建议：
- 为
/tmp挂tmpfs并设大小上限 - 给
/var/log配logrotate，启用maxage和create - 新建文件系统时预估小文件规模，格式化时用
mkfs.ext4 -T small
