Linux inode 用尽的真实原因_网络技术_宿州市腾雀网络科技有限公司

“No Space Left on Device”常因inode耗尽而非磁盘空间不足；每个文件独占一个inode，总数在格式化时固定，df -h无法反映，须用df -i查看IUse%；高危目录包括/var/log、/tmp、/var/spool/postfix/maildrop等小文件密集区。

这不是磁盘真满了，而是 inode 耗尽了——系统没地方给新文件“登记身份”。Linux 中每个文件（包括空文件、软链接、socket、甚至一个 0 字节的 touch test）都必须绑定一个唯一的 inode。这个编号在格式化时就固定了总数，用完即止，和磁盘剩余容量完全无关。

典型场景：/var/spool/postfix/maildrop 下堆积几十万封未发送邮件（每封一个文件），总大小可能才几 MB，但占光了整个分区的 inode
常见错觉：看到 df -h 显示 / 还剩 20GB，就以为还能写；必须用 df -i 看 IUse% 列，>95% 就得警觉
注意：df -h 和 df -i 查的是两套独立资源，不能互相替代

1 个 1GB 文件只用 1 个 inode，而 100 万个 1KB 日志碎片会吃掉 100 万个 inode。真实高危目录往往不是你想象中的数据盘，而是系统自动产出、无人清理的“副产品区”：

/var/log：Nginx access.log 每秒切 1 个碎片？logrotate 配置漏了 compress 或 rotate 30，就会留下海量 .log.1、.log.2.gz…
/tmp 和 /var/tmp：临时解压、编译缓存、Docker 构建中间层，程序
崩溃后不清理，文件残留但无名无主
/var/cache：apt/yum 缓存包、systemd journal 归档、浏览器 profile 缓存，尤其 journalctl --vacuum-size=100M 不设就滚雪球
/proc 和 /sys 不计入统计，但 /dev/shm 是 tmpfs，它的 inode 来自内存，满了一样卡死

inode 总数在 mkfs.ext4 时就写死在超级块里，运行中无法增减。有人想用 tune2fs -i 或 resize2fs，但这些命令只调预留比例或数据块，不碰 inode 总量。

唯一可靠办法：备份 → 新建更大 inode 密度的文件系统 → 恢复。例如：mkfs.ext4 -i 4096 /dev/sdb1（每 4KB 数据块配 1 个 inode，比默认 8KB 更密），适合日志/容器等小文件场景
线上系统不敢重格？那就只能靠“腾挪”：把 /var/log 挂到新分区，再用 ln -s 保持路径不变
别信“在线扩容 inode”的脚本——那是伪造统计或改显示值，底层没变，touch 依然失败

有些行为看似 harmless，实则静默产 inode，排查时容易跳过：

cron 脚本 stdout 未重定向 → 默认发邮件 → postfix 把每封未送达邮件存成一个文件在 /var/spool/postfix/maildrop/
rsync 备份时加了 --delete 却没加 --delete-delay，中途断连导致大量 .~tmp~ 零碎文件残留
容器 runtime（如 containerd）的 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/ 目录下，未 gc 的快照层含海量元数据文件
ext4 的 dir_index 特性开启后，大目录本身会多占 inode（用于哈希索引），ls /var/lib/rpm 慢不一定是磁盘问题，可能是目录 inode 溢出

查的时候别只盯着 find / -type f | wc -l —— 它慢且不准；优先用 du --inodes -sh /* 2>/dev/null | sort -rh，快、准、带排序，一眼定位根因目录。