当 df -i 显示 inode Use% 为 100% 时即确认 inode 耗尽，即使 df -h 显示磁盘空间充足；需检查各挂载点（如 /var、/home），定位高文件数目录并清理残留小文件，注意已删除但被进程占用的文件需重启或重载服务释放 inode。
怎么确认是不是 inode 耗尽了
当 df 显示磁盘空间还有富余，但新建文件报 No space left on device，就要怀疑 inode 用尽。直接看 inode 使用率：
df -i重点关注
Use% 列——哪怕 Capacity% 才 10%，只要 Use% 是 100%，就是 inode 耗尽。
常见误判点：只查 df -h，漏掉 -i；或只查根分区，忽略 /var、/home 等独立挂载点（它们有各自的 inode 池）。
哪些场景最容易吃光 inode
小文件密集型应用是头号元凶，比如：
-
rsync或备份脚本未清理临时文件，残留大量.~tmp、.partial - Web 服务（如 Nginx、Apache）日志未轮转，或启用了细粒度访问日志（每请求一行 + 每秒千级请求 → 每天百万小文件）
- 邮件服务器（如 Dovecot）每个邮件存为单独文件，用户积压未归档
- 容器环境里，频繁创建/销毁的
ephemeral卷或未清理的/tmp下的 socket、pid 文件
快速定位高 inode 占用目录
从根开始逐层找“文件数最多”的子目录，避免全盘 find 耗时过长：
find /var -xdev -type d | while read d; do echo "$(find "$d" -maxdepth 1 -type f | wc -l) $d"; done | sort -nr | head -10
说明：-xdev 防止跨文件系统；maxdepth 1 限制只统计当前目录下文件（不含子目录），加快速度。结果第一列是文件数，第二列是路径。
更轻量的替代方案（适合交互式排查）：
du --inodes -s /var/* 2>/dev/null | sort -nr | head -5注意：
du --inodes 统计的是目录及其所有子孙文件，比上面更准但稍慢。
清理后 inode 为什么没立刻释放
删除文件只是解除链接，如果还有进程在打开它，inode 不会被真正回收。检查方法：
lsof +L1会列出所有已删除但仍被进程持有的文件（
DEL 状态）。常见于：
- 长期运行的服务（如 Java 应用）打开了旧日志，而日志轮转脚本只重命名不重启进程
- shell 脚本中用
cat file > /tmp/log重定向，但file被删后，重定向句柄仍占用 inode
解决办法：杀掉对应进程，或让其 reload（如 systemctl reload nginx）；不能 reload 的，至少要 kill -HUP 尝试触发重新打开文件。
另外，XFS 文件系统在大目录删除后可能延迟回收 inode，需等 xfs_repair 或下次挂载时才彻底释放——这不是 bug，是设计权衡。
