磁盘还有空间，Linux 却提示 No space left on device
区分 Linux inode 耗尽与已删除但仍打开的文件，避免盲目清理或重启所有服务。
紧急情况： 应用无法创建新文件。有人删除了大型日志，但可用空间没有增加；或者容量报告仍有余量，No space left on device 却持续出现。继续删除前，先确认究竟耗尽了什么资源。
检查真正报错的路径
以下 /var 只是示例，应替换成应用实际发生错误的目录。这些命令用于 Linux 诊断：
findmnt -T /var
df -h /var
df -i /var
sudo lsof +L1
df -h 显示数据块使用量，df -i 显示 inode 情况。对存在此限制的文件系统，即使数据容量尚有剩余，inode 耗尽也可能阻止创建文件。应用路径可能位于另一个挂载点，只看根文件系统容量并不足够。
如果 inode 已耗尽
限制大量小文件的生成源，例如每次失败后都创建临时文件的异常任务。清理应限定具体目录，并了解负责人及保留规则。可重建缓存不等于原始数据、工作队列或事务文件。
在同一文件系统内移动文件，通常不会释放 inode。目标是减少该文件系统上真正无用的文件，而不是仅整理目录名称。如果文件生成原因仍然存在，清理只能争取短暂时间。
如果文件已删除但仍打开
lsof +L1 可以显示链接数小于一的已打开文件。将相关的大文件记录关联到 PID 及所属服务。进程可能仍持有已删除文件；移除文件名不代表所有数据块立刻释放。
如果文件是该服务日志，应查看产品文档中的重新打开日志方法。若没有此机制，在理解影响后有控制地重启该服务，可能释放句柄。仅出现“deleted”不代表可以结束进程。不要通过操作 /proc 路径或清空文件描述符来修复数据库文件。
如何确认处理完成
在同一路径重新检查容量与 inode。通过应用执行小规模、已授权的创建和写入测试，并观察后续增长。如果证据不符合上述情况，应分别检查配额、只读文件系统和存储故障；不要把 ENOSPC 一律归因于日志。
关键决策： 再次删除前，确认是数据块不足、inode 耗尽，还是进程仍占用已删除文件的空间。
