诡异的故障来了：df -h 显示磁盘才用了 60%，可程序写文件报 No space left on device。df 明明说有空间。这局面的答案通常藏在一个叫 inode 的东西里——df -h 看的是字节空间，df -i 看的是文件数量配额，两个都满才算真满。
解释一下原理：每个文件都要占用一个 inode（索引节点），inode 总数在文件系统创建时就固定了，ext4 上大约是每 16KB 空间配一个 inode。海量小文件——几十万个 session 文件、缓存碎片、邮件队列残留——很快就能把 inode 吃光，哪怕一个文件才几百字节。字节没满、inode 满了，写入照样报 device full，这是 Linux 磁盘故障里最经典的一种障眼法。
# 第一步：看 inode 使用率（IUse% 接近 100% 就是它）
df -i
# 第二步：找到小文件扎堆的目录
du --inodes -x / 2>/dev/null | sort -rn | head -10
# 老系统没有 du --inodes 时，用 find 统计替代
find /var -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -rn | head
定位到重灾区后，清理要讲策略。常见重灾区是 PHP 的 session 目录（session 堆积几百万个小文件）、/tmp 残留、cron 邮件队列（/var/spool/mqueue 或 /var/spool/cron 产生的堆积）。清理大量文件时千万别用 rm -f 加通配符——目录下文件太多时 shell 直接报参数列表过长，而且 rm 遍历巨慢，正确姿势是 find 配 -delete。
# 安全清理示例：删 7 天前的 session 文件（-delete 比 rm 快且稳）
find /var/lib/php/session -xdev -type f -mtime +7 -delete
# 每次删完看一眼 inode 回落情况
df -i /var
# 分批删更稳：每次只删 5000 个，删完确认服务无异常再继续
find /tmp/cache -xdev -type f -mtime +3 | head -5000 | xargs -r rm -f
删大量文件还有个暗坑：在 ext4 上，某些版本的内核对正在大量删除的目录持有锁，可能出现 rm/find 卡死、df -i 的数字迟迟不回落。用 lsof +L1 看有没有被进程占着的已删除文件，有就重启对应服务释放。如果 inode 长期不够用，治本方案有两条：一是在下次格式化时用 mkfs.ext4 的 -T news 或 -N 参数调高 inode 密度；二是把海量小文件的场景改掉——session 存 Redis，缓存统一走对象存储，从源头减少文件数量。
最后把这类故障的排查口诀留给各位：磁盘写不进，先 df -h 再 df -i，两个 100% 要分开治；小文件海是元凶，du --inodes 找窝点；清理用 find -delete，治本靠改存储。这套动作熟练之后，五分钟内能从“诡异的写失败”走到“删除 session 目录治百病”。
相关阅读：inode 耗尽是磁盘满的孪生故障。《服务器故障排查总纲：按现象反查的五层定位法》系统层的这两篇对照着看，df 和 du 的差异、小文件从哪来，一次讲清。
A5创业网 版权所有