Linux inode 用尽时，最典型的现象是：磁盘空间还有余量（df -h 显示 Use% 远低于 100%），但新建文件失败，报错 No space left on device。这说明不是空间不够，而是索引节点（inode）池已耗尽——每个文件、目录、符号链接都独占一个 inode，小文件多、清理不及时就容易触发。
确认是否真为 inode 耗尽
执行 df -i，重点看 IUse% 列：
- 只要任意挂载点的 IUse% 达到 100%，即确认 inode 耗尽
- 不要只查根分区（/），务必检查
/var、/home、/tmp等独立挂载点——它们各自拥有独立的 inode 池 - 常见误判：仅运行
df -h就下结论，或看到 / 分区 IUse% 正常就停止排查
快速定位高 inode 占用目录
避免全盘扫描耗时过长，推荐分层聚焦：
- 对可疑挂载点（如
/var）运行：du --inodes -s /var/* 2>/dev/null | sort -nr | head -5
结果按 inode 数从高到低排序，第一列是数量，第二列是路径 - 若发现某子目录（如
/var/spool/postfix/maildrop或/var/spool/clientmqueue）异常突出，进入该目录进一步确认：find . -maxdepth 1 -type f | wc -l - 典型高产目录包括：
/var/spool/下邮件队列、/tmp中未清理的临时文件、应用日志缓存目录、定时任务输出堆积目录
清理与释放 inode 的关键操作
删除文件只是解除硬链接，inode 是否真正回收取决于是否有进程仍在占用：
- 直接清理大量小文件时，避免
rm *报参数超长错误，改用：ls | xargs -n 1000 rm -f - 运行
lsof +L1或lsof | grep deleted，列出所有已删除但被进程打开的文件（状态为 DEL） - 对这类文件，需重启对应服务（如
systemctl restart postfix）或终止进程，才能释放 inode - 若属 cron 任务产生（如每分钟同步时间脚本输出邮件失败），应修复邮件服务或重定向输出（
>/dev/null 2>&1）
长期预防建议
单纯清理是治标，机制优化才能防复发：
- 为高频生成小文件的服务配置自动轮转或定期清理（如 logrotate 配置
daily+maxage 7） - 检查 crontab 任务，禁用无意义的频繁执行项，或确保其输出被重定向
- 对
/var/spool/类目录设置磁盘配额或监控告警（如 Prometheus + node_exporter 的node_filesystem_files_free指标） - 系统盘扩容可同步增加 inode 总数（格式化时 inode 数与分区大小正相关），但无法动态调整现有分区的 inode 总量
