磁盘满了？不，是 inode 被榨干了！

傲来云

在日常 Linux 运维中，我们习惯把“磁盘满了”理解为容量用光，但实际还有另一种更隐蔽的情况——inode 耗尽。一旦 inode 被用光，即使磁盘还有大量剩余空间，也会出现无法写入文件的情况。本文分享一次真实案例的排查与解决过程。

一、问题现象
系统：CentOS 7
环境：Nginx + PHP-FPM + MySQL
故障表现：
网站突然 500 报错
日志文件无法写入
touch 新文件报错：

1. No space left on device

复制代码

df -h 查看磁盘空间并未满：

1. Filesystem      Size  Used Avail Use% Mounted on
   
2. /dev/vda1        40G   18G   20G  48% /

复制代码

这时很多人会一头雾水：剩余 20G 空间，为什么还提示“设备没有剩余空间”？

二、第一步：怀疑 inode 问题
inode（index node）是 Linux 文件系统用来存储文件元数据的结构，每个文件、目录都会占用一个 inode，一旦 inode 被耗尽，就无法创建新文件。
检查 inode 使用情况：

1. df -i

复制代码

输出：

1. Filesystem     Inodes  IUsed  IFree IUse% Mounted on
   
2. /dev/vda1     2621440 2621440     0  100% /

复制代码

果然——inode 使用率 100%。

三、第二步：定位 inode 消耗源
inode 耗尽的原因通常是某个目录下产生了大量小文件。我们需要找到这些“元凶”。
统计根目录下各文件夹 inode 使用情况：

1. for i in /*; do echo $i; find $i | wc -l; done

复制代码

或者更直观地统计前几名：

1. sudo du --inodes -x / | sort -nr | head

复制代码

输出示例：

1. 1500000 /var/cache/nginx/proxy_temp
   
2. 900000  /var/log/app
   
3. ...

复制代码

发现 /var/cache/nginx/proxy_temp 下有 150 万个临时文件，瞬间真相大白。

四、第三步：解决问题
1. 清理无用文件

1. rm -rf /var/cache/nginx/proxy_temp/*

复制代码

2. 重启相关服务

1. systemctl restart nginx

复制代码

3. 再次检查 inode 使用情况

1. df -i

复制代码

确认 inode 已释放，网站恢复正常。

五、第四步：预防措施
1. 定期清理缓存和临时文件
使用 tmpwatch 或 systemd-tmpfiles 自动清理：

1. tmpwatch --mtime 24 /var/cache/nginx/proxy_temp

复制代码

2. 调整 Nginx 缓存策略
在 nginx.conf 中设置合理的缓存大小与过期时间：

1. proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=cache:10m max_size=1g inactive=1d;

复制代码

3. 监控 inode 使用率
使用 Zabbix、Prometheus 或简单的 cron 脚本，提前告警：

1. df -i | awk '{ if ($5+0 > 80) print $0; }'

复制代码

4. 大文件优先存储到专用磁盘
业务中如果会产生大量小文件，可考虑合并打包、存储到对象存储（OSS、S3）。

六、经验总结
磁盘可用空间充足 ≠ 没有存储问题，inode 耗尽同样致命。
遇到 No space left on device 报错，第一时间用 df -i 检查 inode。
大量小文件的积累往往是定时任务、缓存策略不当或日志未清理造成的。
养成监控 inode 的习惯，可以避免线上业务中断。

总结
在 Linux 下，磁盘健康不仅是容量，还有 inode。容量是“仓库的大小”，inode 则是“货架的数量”，货架满了，仓库再大也没用。