磁盘还有空间却提示 No space left on device：inode、删除未释放与配额排查

df -h 明明显示还有剩余空间，应用却报 No space left on device，原因通常不在磁盘容量本身，而是 inode 耗尽、文件被删除后仍被进程占用、用户配额、只读文件系统或容器存储层异常。

一、先确认容量和 inode

df -hT
df -i
findmnt -T /path/to/error

df -h 查看数据块，df -i 查看 inode。大量小文件会耗尽 inode，即使仍有几十 GB 空间也无法创建新文件。先确认报错路径实际属于哪个挂载点，避免检查错磁盘。

二、定位小文件风暴

du --inodes -x -d 2 /var 2>/dev/null | sort -n | tail -30
find /var -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -n | tail

常见来源包括邮件队列、PHP Session、临时目录、容器日志、监控缓存和程序错误重试产生的碎片文件。确认业务用途后再清理，不要直接对陌生目录执行批量删除。

三、检查删除但未释放的文件

lsof +L1
lsof | grep '(deleted)'

Linux 文件被删除后，只要进程仍持有文件描述符，空间就不会释放。最安全的处理通常是让对应服务正常重载或重启。若业务不允许重启，可在充分确认后截断 /proc/<PID>/fd/<FD>，但必须评估应用行为和数据风险。

四、比较 df 与 du

df -h /var
du -xsh /var

df 统计文件系统已分配块，du 统计目录树可见文件。两者差距很大时，应重点怀疑删除未释放文件、挂载点被覆盖或文件系统保留块。

五、检查配额和只读状态

quota -s
repquota -a
findmnt -no OPTIONS /path/to/error
dmesg -T | tail -100

用户或项目配额耗尽也会报空间不足。文件系统检测到严重错误后可能被重新挂载为只读，此时应先保存日志并安排文件系统检查，而不是反复写入。

六、容器环境的特殊情况

docker system df
du -sh /var/lib/docker/* 2>/dev/null
journalctl --disk-usage

容器可写层、未使用镜像、构建缓存和 JSON 日志都可能占满宿主机。Kubernetes 节点还应检查 ephemeral-storage、镜像垃圾回收和已驱逐 Pod。清理必须通过容器平台的正常机制完成，避免直接破坏存储目录。

七、预防措施

• 同时监控容量百分比、剩余 GB 和 inode 使用率；

• 日志必须轮转，并验证应用能够重新打开文件；

• 对临时文件、Session 和缓存设置生命周期；

• 定期检查删除未释放文件；

• 容量告警应为扩容和清理预留足够时间。

总结

遇到 No space left on device，按照“确认挂载点—检查容量—检查 inode—检查删除未释放—检查配额和只读状态—检查容器存储”的顺序排查，通常能够快速定位，避免因误删文件扩大事故。