Linux 磁盘满了却找不到大文件？先分清 df、du 和 inode

遇到“No space left on device”时，第一反应常是删除最大的日志。但空间告警可能来自磁盘块不足，也可能来自 inode 耗尽；即使删除文件，空间也未必立刻释放。更稳妥的做法是先确认哪个文件系统出问题，再解释统计差异。本文以 GNU/Linux 常见命令为例，所有示例均用于读取状态，不执行清理。

一、先定位报错路径属于哪个文件系统

假设应用把数据写到 /var/lib/example，可用 df -h /var/lib/example 查看它所在文件系统的容量与使用率。路径应替换为实际存在的目录；若目标尚未创建，先查看其已存在的父目录。不要只运行 df -h 后盯着第一行，因为应用目录可能位于独立挂载盘，而不是根分区。

接着运行 df -i /var/lib/example。inode 可理解为文件系统用于描述文件等对象的元数据资源。某些文件系统存在固定或可用 inode 数量限制，海量小文件可能在容量看似充足时耗尽它。不同文件系统的实现不同，不能把所有空间问题都归结为同一种机制。

二、df 与 du 回答的不是同一个问题

df 询问文件系统的使用情况；du 通过目录遍历统计文件的磁盘占用。两者数字不完全相等，并不能立即证明有“隐藏的大文件”。例如权限不足会导致 du 遍历不全，文件系统元数据和预留空间也不会简单对应目录中可见文件的总和。

在有权限且确认扫描范围合适时，可用 du -x -h --max-depth=1 /var/lib/example 查看该目录第一层的占用。-x 避免跨入其他文件系统，--max-depth=1 限制汇总展示深度，但并不意味着只读第一层文件：工具仍可能遍历更深目录，因此大型目录扫描依然有 I/O 成本。以上选项适用于 GNU du，其他系统需查看各自手册。

三、文件删除后仍可能占用空间

Linux 进程可以继续持有已经从目录中删除的文件。只要相关打开引用没有释放，其数据块仍可能存在，因此 du 看不到文件名，df 却仍显示空间被占用。若系统已安装 lsof，可由具备适当权限的人使用 lsof +L1 查看链接计数小于 1 的打开文件；输出中的设备和路径线索需要与目标文件系统对照，不能看到一条 deleted 就断定它是全部原因。

这一步是观察，不是立即重启。直接杀进程或截断正在写入的文件可能损坏任务、丢失日志或影响服务。确认所属程序后，应按照应用支持的日志轮转、重新打开文件或维护流程处理，并遵守变更授权。

四、还要留意挂载边界和统计方式

目录上挂载了新文件系统时，原目录下已有的内容可能被遮住，但仍占原文件系统空间。不要在生产环境为了查看它而随意卸载。稀疏文件也会让“逻辑大小”和“实际分配块”出现差异，ls 显示的长度不能直接代替 du 的磁盘占用。容器的可写层、卷和宿主机文件系统还可能有不同限制，需要先确定报错来自哪一层。

五、把观察结果写成一句可验证的判断

例如：“数据目录位于某个挂载点，df 显示块使用率高，inode 使用率正常；目录汇总与文件系统统计存在明显差异，待核对打开但已删除的文件。”这种记录比“磁盘坏了”更利于协作。记录时间、目标路径和命令输出中的关键数值，并注意不要公开业务路径或敏感文件名。

小结

空间问题的第一步不是删除，而是分清路径、文件系统、磁盘块与 inode，再解释 df 和 du 的口径差异。先用只读证据缩小范围，再选择经过授权的清理方式，能减少误删与无效重启。