欢迎光临
我们一直在努力

Linux inode 用尽的真实原因

RackNerd Leaderboard Banner RackNerd Leaderboard Banner

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

df -h 显示空间充足,却报 “No Space Left on Device”

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

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

真正耗尽 inode 的不是大文件,而是“看不见的小东西”

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

  • /var/log:Nginx .log 每秒切 1 个碎片?logrotate 配置漏了 compressrotate 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”?格式化才是唯一硬解

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

用AI重新定义音乐创作

  • 唯一可靠办法:备份 → 新建更大 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(如 contnerd)的 /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,快、准、带排序,一眼定位根因目录。

RackNerd Leaderboard Banner
未经允许不得转载:国外主机测评 » Linux inode 用尽的真实原因