磁盘写入失败时，先判断是文件系统容量不足还是 inode 耗尽。容量代表可存储的数据块，inode 代表可描述的文件对象数量；海量几 KB 的文件会先耗尽 inode，而大日志或备份则常占满容量。清理方向必须由指标决定。
执行 df -hT 查看挂载点、文件系统类型和容量使用率，执行 df -i 查看 inode 使用率。先找出报错路径实际属于哪个挂载点，再针对该挂载点调查，避免在根目录搜索时跨入其他卷。普通用户可能因文件系统预留空间而早于特权进程写入失败，因此要结合报错账号和挂载点判断。
容量高、inode 余量充足时，重点找大文件和快速增长目录；inode 使用率接近满时，重点找文件数量异常的目录。若两项都正常，检查用户配额、只读挂载或底层存储错误，不能把所有写入失败都归因于磁盘空间。
使用 du -xhd1 /目标挂载点 查看同一文件系统内的一级目录体量，再对最大的目录逐层下钻。选项 -x 避免统计到其他挂载点；执行范围应从故障路径所属文件系统开始。重点关注应用日志、临时目录、缓存、备份和用户上传数据，并结合文件修改时间判断是否持续增长。
inode 紧张时，按目录统计文件数量或使用文件系统提供的统计工具，不能只看 du 的大小排序。大量小型会话文件、缓存碎片或错误循环产生的日志片段，可能占用很多 inode，却只占少量字节。
如果 df 显示空间已占满，但可见目录的 du 总量明显较小，常见原因是文件已删除但仍被进程打开。使用 lsof +L1 可查找链接数归零但仍占用空间的打开文件。释放空间通常需要让对应进程按安全流程重新打开文件；不要直接终止关键数据库或队列进程。
清理或修复后，对相同挂载点再次运行 df -hT 和 df -i，确认容量与 inode 都有足够余量。随后验证应用能创建文件、日志可继续写入，空间告警恢复正常。若增长源是日志或缓存，应补上有上限的保留策略，并观察一段时间增长速率；一次释放空间并不能证明根因已消失。
