“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，但占光了整个分区的 inode - 常见错觉：看到
df -h显示/还剩 20GB，就以为还能写；必须用df -i看IUse%列，>95% 就得警觉 - 注意：
df -h和df -i查的是两套独立资源，不能互相替代
真正耗尽 inode 的不是大文件，而是“看不见的小东西”
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”？格式化才是唯一硬解
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，快、准、带排序，一眼定位根因目录。
