df -i 显示任意挂载点 IUse% 为 100% 即确认 inode 耗尽；各挂载点 inode 池独立，需逐个检查 /var、/home 等路径；常见高危目录包括 /tmp、/var/spool、/var/log/journal；用 du --inodes 定位大户，lsof +L1 查已删未释文件，清理后需重启占用进程方可释放 inode。
df -i 显示 IUse% 100% 就是 inode 耗尽
只要 df -i 输出中任意挂载点的 IUse% 达到 100%，基本可以锁定问题根源。注意：各挂载点的 inode 池完全独立，/ 分区 inode 充足不代表 /var 或 /home 也安全。常见高危路径包括：/tmp、/var/spool、/var/log/journal、/var/lib/docker/overlay2。别只盯着 df -h 看“还有 20GB”，那只是数据块有空，inode 可能早被几百万个 1KB 日志碎片吃光。
用 du --inodes 快速定位“产 inode 大户”
在疑似挂载点下执行：du --inodes -s /path/* 2>/dev/null | sort -nr | head -5。这个命令按子目录消耗的 inode 数量倒序排列，前五名就是重灾区。比如发现 /var/log/journal 异常突出，就进去确认：find /var/log/journal -type f | wc -l。如果返回几十万，大概率是 systemd-journald 日志没轮转或限制。此时别直接删整个目录，先查占用：journalctl --disk-usage，再收缩：journalctl --vacuum-size=100M。
删了文件但 df -i 不变？检查被进程占用的“僵尸 inode”
文件被 rm 后，若仍有进程打开它（比如日志服务正在写入），inode 不会立即释放。运行：lsof +L1 或 lsof | grep deleted，能列出这类“已删未释”的文件及其 PID。常见处理方式：
- 重启对应服务：
systemctl restart rsyslog或systemctl restart docker - 若无法重启，可临时 kill 进程：
kill -9 <pid></pid> - 慎用
find /tmp -name "sess_*" -delete这类命令——参数过长可能报错，改用find /tmp -name "sess_*" -print0 | xargs -0 rm -f
ext4 文件系统 inode 数量无法在线扩容
inode 总数在 mkfs.ext4 格式化时就固定了，后续无法动态增加。所以清理只是治标，长期方案得从源头控制小文件爆炸：
- 为
/tmp挂tmpfs并设大小上限，重启自动清空 - 给
/var/log配logrotate，启用maxage和create选项 - 检查 crontab，禁用高频无意义任务，或重定向输出：
>/dev/null 2>&1 - 新建文件系统时预估规模：
mkfs.ext4 -T small（小文件多）或-T largefile（大文件少）
真正棘手的是那些已经跑了几个月的生产系统——inode 耗尽往往意味着业务逻辑在持续生成小文件，光清一次没用，得回溯源头改行为。
