Linux inode 用尽问题排查

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 总量