df -i 是唯一能直接查看挂载点 inode 占用的命令，必须优先执行以确认目录所属分区的 inode 使用率；IUse% ≥ 95% 即需立即处理，重点关注 /、/var、/home 等业务挂载点，忽略 tmpfs 等内存文件系统高使用率。
df -i 是唯一能直接看挂载点 inode 占用的命令
想确认某个目录所在的分区是否快耗尽 inode，df -i 是第一且必须执行的动作。它不查目录本身，而是查该目录所属的挂载点——这才是 inode 分配的实际单位。
常见误判点：df -i /var/log 和 df -i /var 通常输出一样，因为它们属于同一挂载点；但 df -i /home 可能完全不同，尤其当 /home 是独立分区时。
-
IUse%≥ 95% 就得立刻处理，别等报错才动手 - 重点关注
Mounted on列：/、/var、/home、/boot 这些实际存业务数据的挂载点 - tmpfs、devtmpfs 也会出现在
df -i输出里，它们的高使用率是正常的，别慌 - 某些精简系统或容器镜像里
df -i不显示IUse%列，此时改用stat -f /查Inodes:和Inodes Free:字段手动算
du --inodes -s 比 find | wc -l 更准
find /path -type f | wc -l 只统计普通文件，漏掉目录、软链接、设备节点——它们也都各占一个 inode。真正反映“这个目录树总共吃了多少 inode”的，是 du --inodes -s。
实操建议：
- 快速扫一级子目录：
du --inodes -s /var/* 2>/dev/null | sort -nr | head -5 - 加
2>/dev/null是为了屏蔽权限不足报错，否则排序会被打断 - 结果第一列是 inode 数，第二列是路径；数值异常高就进去深挖
- 别用
ls -a | wc -l查大目录——文件超 10 万就容易崩，memory exhausted是常见错误
ls -i 和 find -inum 用来定位硬链接和重复 inode
当你怀疑某目录下存在大量硬链接（比如日志归档、备份快照），或者想验证两个文件是否指向同一个 inode，ls -i 和 find -inum 是最直接的工具。
注意点：
-
ls -i /tmp输出格式是 “inode号 文件名”，每行一个条目 - 搭配
awk '{print $1}' | sort | uniq -c | sort -nr | head -5能快速揪出出现频率最高的 inode 号（意味着多个硬链接） -
find /path -inum 123456会列出所有指向该 inode 的路径；但对已删未释放的文件无效（这类文件只在/proc/PID/fd/下可见） - 软链接不会共享 inode，
ls -i显示的是软链接自身的 inode，不是目标文件的
清理前必须确认三件事
删文件不等于立刻释放 inode，尤其在线上环境。最容易被忽略的三个检查点：
- 先跑
lsof +L1—— 查有没有硬链接数为 0 但进程仍在写的“已删未释放”文件，常见于 Java、nginx 日志轮转后没 reload - 进高 inode 目录后，用
ls -U | head -n 20看文件名时间戳是否密集（比如全是同秒生成），大概率是失控的 cron 脚本在写临时邮件或日志 - 删小文件别用
rm -rf *，会触发Argument list too long；改用find /path -maxdepth 1 -type f -delete或find /path -name "sess_*" -print0 | xargs -0 rm -f
真正难处理的从来不是文件数量，而是那个每分钟新建一个空文件却没人管的定时任务——它往往藏在 root 的 crontab 里，名字朴素如 sync.sh，不翻日志根本找不到。
