Linux inode 用尽排查完整流程：df -i、find 定位和清理归档

Linux 服务器上有一种问题很容易误判：df -h 看磁盘空间还有不少，但应用写文件时却报 No space left on device。如果只盯着容量，很可能会绕一圈才发现真正问题是 inode 被大量小文件耗尽。

本文按完整工作流来处理：先定边界，再确认容量和 inode，再定位小文件目录，最后把清理、归档、日志轮转和监控一起补上。目标不是只删掉一批文件，而是让同类问题下次能提前发现。

目录

• 目标和边界：先确认要解决什么
• 全流程总览：从写入失败到 inode 恢复
• 阶段 1：用 df -h 和 df -i 分清容量与 inode
• 阶段 2：用 find 找到小文件集中目录
• 阶段 3：清理、归档和日志轮转一起落地
• 我的推荐工作流
• 容易踩坑的地方
• 速查表

目标和边界：先确认要解决什么

这类问题的目标很明确：让应用恢复写入，同时找出 inode 被谁消耗掉，避免只靠临时删除文件续命。

本文默认场景是普通 Linux 服务器上的应用目录、日志目录、缓存目录或临时文件目录。不会展开文件系统底层原理，也不会讨论重新格式化分区这种高风险操作。线上处理时，任何删除动作都应该先确认目录归属、业务影响和保留周期。

全流程总览：从写入失败到 inode 恢复

先把路线图放出来。遇到写入失败时，不要只看 df -h。容量正常并不代表还能创建文件，inode 用完同样会导致创建失败。

这条链路里的关键判断是：如果 df -h 显示容量还够，但 df -i 显示 IUse% 接近 100%，那就应该把排查重点转到“小文件数量”上。

阶段 1：用 df -h 和 df -i 分清容量与 inode

目标

确认当前报错到底是磁盘容量不足，还是 inode 不足。两个问题处理方式不同，不能混在一起看。

关键动作

先看容量：

df -h

再看 inode：

df -i

如果看到类似下面的结果，就说明 inode 已经被打满：

Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      1310720 1310720     0  100% /

检查点

阶段 2：用 find 找到小文件集中目录

目标

inode 用尽通常不是一个大文件导致的，而是大量小文件堆出来的。下一步要找出文件数量最多的目录。

关键动作

可以先从常见目录缩小范围，例如 /var、应用缓存目录、上传临时目录、日志目录：

find /var -xdev -type f | sed 's#/[^/]*$##' | sort | uniq -c | sort -nr | head -20

这条命令的思路是：列出文件，转换成所在目录，按目录统计文件数量，再取数量最多的前 20 个。结果可能类似：

245000 /var/cache/app/session
 82000 /var/log/app/request
 35000 /var/tmp/upload

检查点

定位目录后，先确认这些文件是否能清理：

• 是不是业务仍在读取的文件。
• 是否有明确保留周期，比如 7 天、30 天。
• 是否需要先归档，再删除本地旧文件。
• 是否由应用异常产生，比如失败重试不断写临时文件。

阶段 3：清理、归档和日志轮转一起落地

临时恢复可以先清理确认过的旧文件，但真正稳定的方案应该包含三件事：批量清理、日志轮转、监控告警。

目标

把 inode 使用率从危险区降下来，并让新增小文件有固定生命周期。

关键动作

清理 7 天前的缓存文件示例：

find /var/cache/app -type f -mtime +7 -print0 | xargs -0 -r rm -f

归档 30 天前的日志示例：

mkdir -p /data/archive/app-log
find /var/log/app -type f -mtime +30 -print0 | xargs -0 -r tar -rf /data/archive/app-log/old-files.tar

归档完成后，再根据业务确认是否删除本地旧文件。对于持续增长的日志目录，优先配置轮转策略，让单个目录不会无限堆文件。

检查点

清理后再次查看 inode：

df -i

如果 IUse% 从 100% 降到安全区，应用也能正常写入，说明恢复动作有效。下一步就不是继续手动删除，而是补监控和自动清理策略。

我的推荐工作流

1. 先记录应用报错时间、目录和服务名。
2. 运行 df -h，排除容量用尽。
3. 运行 df -i，确认 inode 使用率。
4. 用 find 在对应挂载点下统计文件数量最多的目录。
5. 确认目录归属和保留周期，先归档或清理过期文件。
6. 再次运行 df -i 和应用写入测试。
7. 补上日志轮转、缓存过期、inode 使用率告警。

容易踩坑的地方

• 只看 df -h：容量正常不代表 inode 正常，写入失败时两个命令都要看。
• 直接全盘查找：大机器上全盘扫描很慢，先按挂载点和业务目录缩小范围。
• 不确认目录归属就删除：缓存、会话、上传临时文件的业务影响不同，删除前必须确认。
• 只清理不治理：如果生成小文件的逻辑还在，inode 迟早会再次打满。
• 没有告警阈值：建议对 inode 使用率设置 80%、90% 两级提醒。

速查表

总结一下：遇到 No space left on device，不要只盯容量。先用 df -h 和 df -i 把问题分型，再用文件数量定位目录，最后把清理策略和监控补上。这样处理一次，后面同类问题就不会靠猜。