Linux 怎样按 inode 数量定位目录异常

有一类 Linux 磁盘故障很容易误判：df -h 看着还有空间，但服务创建临时文件失败，或者包管理器提示无法创建文件。此时要查的不是目录占了多少字节，而是 inode 是否接近耗尽。确认 inode 使用率后，可以用 du --inodes 按目录统计，再逐层缩小范围。

官方地址：https://man7.org/linux/man-pages/man1/du.1.html

du --inodes 统计的是目录树里的 inode 使用情况，不是文件大小。排查时先用 df -i 判断文件系统是否真的紧张，再用 du --inodes --max-depth=N 找出贡献最大的目录。

先确认异常来自 inode 而不是容量

inode 可以理解为文件系统为文件、目录和其他对象分配的记录。大量小文件会先消耗 inode，即使总字节数还没有达到磁盘容量上限。因此第一步应同时看块空间和 inode 使用率：

# 查看目标文件系统的容量和 inode 使用率
df -h /var
df -i /var

如果 df -i 中的 IUse% 已经很高，而 df -h 仍有余量，就把排查重点转到“哪个目录产生了过多文件”。不要直接把 du -h 的结果当成答案，因为它默认围绕设备空间汇总。

用 du --inodes 看目录的 inode 分布

GNU du 的 --inodes 选项会把统计口径从块空间切换为 inode。先限制层级，得到一张可读的目录地图：

# 只统计 /var 下两层目录，并隐藏无权限目录的噪声
sudo du --inodes --max-depth=2 /var 2>/dev/null

# 按 inode 数量从小到大排序，末尾几行优先查看
sudo du --inodes --max-depth=2 /var 2>/dev/null | sort -n | tail -n 20

输出的数值应当按 inode 数量理解，路径是对应目录树的汇总结果。父目录通常包含子目录的统计，所以它比任意一个子目录大是正常的；真正值得关注的是同一层级中明显偏大的分支。

用边界和排序逐层定位异常目录

根目录下常常挂着其他文件系统。若把它们一起递归，统计结果会混入不属于当前排查对象的内容，因此可以加 --one-file-system（短选项是 -x）：

# 只在当前文件系统内统计，避免把挂载点一起算进来
sudo du -x --inodes --max-depth=2 /var 2>/dev/null | sort -n | tail -n 20

# 假设 /var/lib/app 是最大的分支，再向下多看一层
sudo du -x --inodes --max-depth=3 /var/lib/app 2>/dev/null | sort -n | tail -n 30

下钻时保持同一套参数，只替换起点路径，这样前后数字才容易比较。若某个目录突然变大，下一步再按业务判断是日志切片、缓存碎片、队列落盘文件，还是某个任务没有清理临时文件；du 只负责定位，不会替你决定哪些文件可以删除。

如果输出为空或某些路径缺失，优先考虑权限不足、路径已在扫描期间变化，或者当前系统的 du 实现不支持 GNU 长选项。不要为了“看全”直接扩大到整个根目录并忽略错误输出，这会让结果更慢也更难解释。

读懂结果后再决定清理动作

排查的结论应写成“哪个文件系统、哪个目录分支、为什么文件数量异常”，而不是只记录一行最大的数字。删除前先确认文件的所有者、生命周期和是否仍被进程使用；如果只是临时缓解，可以先停止产生文件的任务，再按保留策略清理。

常见问题

为什么 df -h 还有空间，创建文件却失败？

因为文件系统可能先耗尽 inode。每个新文件都需要 inode 记录，字节空间有余量并不代表还能创建更多文件。

du --inodes 和 du -h 能同时看吗？

它们回答的是不同问题：前者看 inode 使用，后者看设备空间。排查文件数量异常时先看前者，判断大文件占用时再看后者。

为什么要限制 max-depth？

限制层级能先建立目录分布，再对最大的分支下钻；一开始递归全部深度会产生大量输出，难以看出哪个父目录值得继续调查。

把流程固定为“df -i 确认指标 → du --inodes 汇总 → sort 排序 → 更深层级下钻”，就能把 inode 异常从模糊的创建失败，收敛到可处理的目录分支。