Linux inode 用尽问题的排查与解决

当 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，是设计权衡。