在 Linux 服务器运维中，磁盘使用率达到 100% 是常见的告警场景。常规的排查路径是定位并清理大文件，但运维人员时常会遇到一个现象：df 命令显示磁盘已满，而 du 统计的目录总使用量却明显低于磁盘占用。

这一矛盾现象并非统计错误或灵异事件，根本缘由在于：文件已被删除，但仍有进程持有该文件的打开句柄，导致存储空间未被内核真正释放。

我们系统分析了磁盘空间异常的两种成因，并重点阐述文件删除后空间未释放问题的原理、定位方法与标准处理流程等问题。

场景一：文件系统层大文件定位与处置

这一类问题是最直观的，就相当于咱么在家中找到最占地方的“大件”，决定是扔、是压，还是换个大衣柜。我们可以根据“宏观定位 → 逐层深入 → 决策处置”这三个层级来进行排查分析。

01.宏观视角：锁定问题“重灾区”

在终端执行 df -h命令可以直观的看到各分区磁盘空间的使用情况以及剩余空间，定位到空间占用过高的分区，列如说看root分区。

02.微观定位：逐级定位“罪魁祸首”

确定目录后，需要精准定位大文件，针对目标分区使用du -h命令进行逐级定位排查，例如执行du -h命令逐级定位，根据文件大小排序，找到占用空间最大的文件。

03.判断处理，释放空间

查看文件内容，确认一下是否需要保留如果需要保留就通过压缩导出，不需要保留可以直接删除，或者对磁盘进行扩容。例如:（可以直接使用 find 命令查找目录下大于400MB的文件名称，然后进行删除 find 目录-size +400M文件。）

场景二:没有大文件但空间依然是满的

此场景更为隐蔽，表现为：df-h 显示磁盘空间已满，这是由于部分文件已经删除了。但是有一个文件直接导入，导致文件占用空间未释放。这里的处理步骤呢也是分为两步。

01.揪出仍在占用已删除文件的进程

执行 lsof | grep deleted。lsof（list open files）列出系统所有打开的文件，grep deleted 过滤出已被删除但仍被进程占用的文件项。输出中将包含进程PID、命令名及文件大小等关键信息。

02.安全释放空间

对于非核心进程：确认后可对其发送 kill -9 PID 信号终止进程，空间立即释放。

对于核心服务进程（如数据库、Web服务）：应通过 systemctl restart service_name 或向进程发送优雅重启信号（如 kill -HUP PID）进行重启，避免服务中断。重启后，文件句柄关闭，空间自然释放。

关键注意：直接终止核心业务进程可能导致数据丢失或服务异常，务必在理解进程作用后操作。