df 显示磁盘还有空间却无法写文件：Linux inode 耗尽排查与治理

应用报 No space left on device，但执行 df -h 明明还有几十 GB 空间。这类看似矛盾的问题，常见原因不是磁盘容量耗尽，而是 inode 用完了：文件系统还能容纳数据块，却已经无法再创建新的文件和目录。

bash 复制代码

df -hT
df -ih

df -hT 看数据块使用率，df -ih 看 inode 使用率。如果某个挂载点 IUse% 接近 100%，即可确认问题方向。

inode 记录文件的元数据。大量小文件会快速消耗 inode，即使这些文件占用的总容量并不大。

先确认异常挂载点，再在该文件系统内逐层统计。假设问题发生在 /var：

bash 复制代码

sudo find /var -xdev -printf '%h\n' 2>/dev/null \
  | sort | uniq -c | sort -nr | head -30

也可以按一级目录统计文件数量：

bash 复制代码

for d in /var/*; do
  printf '%10s %s\n' "$(sudo find "$d" -xdev -type f 2>/dev/null | wc -l)" "$d"
done | sort -nr | head

-xdev 很重要，它避免跨越到其他挂载点。生产服务器上执行全盘 find 可能产生明显 IO，应该先从异常文件系统和可疑目录开始。

高频来源包括：

检查近期快速增长的文件：

bash 复制代码

sudo find /var -xdev -type f -mmin -60 2>/dev/null | head -100

只输出前 100 条用于观察，不要直接把大规模结果全部打印到终端。

先识别文件的业务用途、保留周期和是否仍被进程使用，再进行清理。常见安全做法包括调用应用自带的清理命令、缩短缓存周期、压缩归档旧日志，以及修复异常生成逻辑。

删除前先抽样：

bash 复制代码

sudo find /var/tmp/myapp -xdev -type f -mtime +7 -print | head -50

确认无误后再按明确目录和条件处理。不要执行来源不明的全盘批量删除命令，也不要删除 /proc、/sys 或容器运行时仍在使用的文件。

清理后复查：

bash 复制代码

df -ih
df -hT

bash 复制代码

docker system df -v
sudo find /var/lib/docker -xdev -type f 2>/dev/null | wc -l

不要直接进入 /var/lib/docker 手工删除文件。应优先删除已确认不再使用的容器、镜像和构建缓存，并在操作前确认回滚和重建方案。

如果业务频繁生成短生命周期小文件，可考虑把临时目录挂载到独立文件系统，避免拖垮根分区。

监控不能只看磁盘容量，还要同时采集 inode 使用率。建议设置分级告警：

部署前还要评估文件数量，而不仅是数据容量。创建文件系统时 inode 密度由文件系统参数决定，调整通常需要重新格式化，因此更重要的是从应用生命周期和目录隔离上治理。

"磁盘有空间但写不进去"时，应立即把 df -ih 加入检查清单。确认异常挂载点后，使用 find -xdev 从局部统计文件数量，抽样确认业务用途，再通过应用清理机制释放 inode。最终还要补上 inode 监控和小文件生命周期策略，避免故障反复出现。