Linux磁盘空间异常占用排查：删除未释放存储空间怎么查看

当你遇到磁盘空间“明明删除了文件却始终没有释放”的问题时，通常直接执行 lsof +L1 就能快速定位原因：输出结果里，NAME 列带有 (deleted) 标记的，就是已经被删除但仍然被进程占用的文件；SIZE/OFF 会显示它实际占用了多少字节，PID 和 COMMAND 则对应具体是哪个进程仍在持有该文件。若权限不足，或这条命令没有查到结果，就继续往更底层排查，使用 find /proc/*/fd -ls 2>/dev/null | grep deleted 进一步定位 Linux 中删除未释放导致的磁盘空间异常占用问题。

怎么用 lsof 找出已删除但仍在占用空间的文件

当 df -h 显示磁盘空间已满，而 du -sh /* 统计出来的总占用却明显小于已使用空间时，大多数情况下，是文件虽然被 rm 删除了，但对应进程仍然保持着文件描述符未关闭——此时数据块不会被真正释放，磁盘空间就会一直被占着。这类文件在 ls 或 du 中通常完全不可见，因此排查 Linux 磁盘空间未释放问题时，必须借助 lsof 来查找。

执行下面这条命令，就可以列出所有这类“已删除但仍占空间”的幽灵文件：

lsof +L1

输出中通常会看到类似这样的内容：

COMMAND PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME
ja va 1234app 12w REG253,0 2845678901 1234567 /var/log/app/nohup.out (deleted)

重点关注以下几项：

• (deleted) 出现在 NAME 列末尾时，就表示该文件已经被删除，但磁盘空间尚未释放
• SIZE/OFF 列的数值越大，说明这个被占用的已删除文件占据的磁盘空间越多，单位为字节
• PID 和 COMMAND 可以帮助你确认到底是哪个进程仍在持有它

lsof +L1 没输出但空间仍对不上，怎么办

在某些环境下，比如容器环境、受限权限用户，或者系统对进程信息访问有限制时，lsof +L1 可能因为权限不足而漏掉结果。这种情况下，可以改用更底层、权限要求相对更低的排查方式：

find /proc/*/fd -ls 2>/dev/null | grep deleted

这条命令会直接扫描所有进程的文件描述符目录，只要内核仍然维护着这个句柄，就有机会把它查出来。虽然输出格式更原始，可读性不如 lsof，但在排查 Linux 删除文件后磁盘空间未释放的问题时往往更可靠。常见场景包括：

• 大量 ja va 或 nginx 进程仍持有 access.log (deleted) 这类已删除日志文件
• dockerd 持有已经删除的容器日志文件或临时层文件，导致磁盘占用异常
• 长期运行的脚本（如 nohup ./run.sh &）把 stdout 重定向到一个后来被删除的输出文件

为什么不能只靠 du 和 df 对比就下结论

du 统计的是当前文件系统目录树中“可见路径”下的实际块占用；而 df 统计的是整个文件系统层面的已分配块总量。因此，两者存在差值，并不一定就说明是“文件已删但空间未释放”。在判断 Linux 磁盘空间异常之前，还需要先排除以下几类常见干扰因素：

• ext4 文件系统默认会为 root 预留 5% 空间：可通过 tune2fs -l /dev/vda1 | grep "Reserved block count" 查询，这部分空间不会显示在 du 结果里，但会计入 df 的 Used
• 挂载覆盖问题：例如 /mnt/data 原本已有文件，后来又挂载了新的磁盘，旧文件会被遮挡，du 无法扫描到，但底层磁盘空间仍然被占用
• tmpfs、overlayfs 等内存文件系统或虚拟文件系统，其空间统计逻辑与真实磁盘块分配并不完全一致

因此，建议先执行 df -i 检查 inode 是否已经耗尽，再结合 tune2fs -l 确认是否存在预留空间，最后再把排查重点放到 lsof +L1 上。这样才能更准确地定位 Linux 磁盘空间占用异常的真正原因，避免误判。

释放这类空间，重启进程是最稳妥的做法吗

不一定。重启进程虽然通常最直接，也最容易彻底释放已删除文件占用的磁盘空间，但在生产环境中未必总是可行。相比之下，还有一些更轻量、对业务影响更小的处理方式：

• 让进程主动重新加载日志，例如 kill -USR1 $(pgrep nginx)，很多服务在收到信号后会关闭旧日志文件描述符并重新创建新的日志 fd
• 手动清空文件内容而不删除句柄：cp /dev/null /proc/1234/fd/12（需要 root 权限，且仅适用于可写 fd）
• 如果确认占用的是某个日志文件，并且应用支持 logrotate，可以直接执行 logrotate -f /etc/logrotate.d/myapp 强制轮转日志

需要注意的是：echo "" > /proc/PID/fd/N 在部分内核版本或某些文件系统上可能会失败，因此使用 cp /dev/null 往往更稳妥。不过，无论采取哪种方式，在操作之前都应先确认该 fd 对应的服务行为和用途——如果盲目截断，可能会导致日志异常、输出错乱，甚至引发程序运行问题。