inode耗尽是“no space left on device”报错但df -h显示空间充足时的主因；需用df -i查iuse%，定位高占用目录，清理残留文件或重启持有deleted文件的进程。
当系统报错 No space left on device，但 df -h 显示磁盘空间仍有余量，大概率是 inode 耗尽。关键不是看“空间”，而是看“文件数量上限”是否触顶。
一、确认是否真为 inode 耗尽
运行 df -i，逐个检查所有挂载点的 IUse% 列：
- 若某挂载点 IUse% 达到或接近 100%，而对应
df -h的 Use% 远低于 90%（比如仅 30%），即可判定为 inode 耗尽 - 切勿只查根分区
/——/var、/home、/tmp等独立挂载点拥有各自的 inode 池，需分别检查 -
df -i结果中 Capacity 列数值固定，由格式化时决定；Use% 是唯一判断依据
二、定位 inode 占用最多的目录
在高 IUse% 的挂载点内执行以下命令，聚焦三级路径以兼顾效率与精度：
-
find /var -xdev -type f | cut -d/ -f1-3 | sort | uniq -c | sort -nr | head -20（替换/var为目标路径） - 对可疑目录进一步验证：
du --inodes -sh * 2>/dev/null | sort -nr | head -5，直接按 inode 数排序子项 - 常见重灾区：
/var/log（轮转失败的日志）、/var/spool/postfix/maildrop（堆积的未发送邮件）、/tmp或/var/tmp（残留临时文件）、/var/lib/docker/overlay2（已删未清理的容器层）
三、识别“已删未释”的 inode
删除文件只是解除硬链接，若进程仍在写入或持有该文件描述符，inode 不会被回收：
- 运行
lsof +L1或lsof | grep deleted，列出所有标记为 (deleted) 的条目 - 重点关注占用大、Node 号重复出现的进程（如
rsyslogd、java、nginx） - 释放方式：重启对应服务，或清空文件内容（如
truncate -s 0 /var/log/app.log），避免中断业务
四、理解 df 与 du 的差异根源
df 和 du 统计逻辑不同，导致结果不一致是常态，而非异常：
-
df读取文件系统超级块元数据，反映整体状态，包含已删未释文件、预留空间（ext4 默认 5%）、日志区、inode 表本身开销 -
du递归遍历可见路径下的文件，仅统计当前能访问到的实体，不计入已删文件、元数据、稀疏文件实际未分配块 - 典型差异场景：
– 进程正写入一个被 rm 删除的大日志 →df计入，du忽略
–postfix队列中大量小文件 →df -i显示 100%，df -h却很低
– 使用fallocate创建的稀疏文件 →ls -lh显示 10G，du显示 0，df按逻辑大小计入
