Linux怎么查看已删除但未释放的句柄 Linux磁盘空间虚假占用详解

Linux磁盘空间虚假占用详解：当df与du的结果“打架”时

想必不少运维同行都遇到过这个经典的“灵异事件”：df -h 明明白白告诉你磁盘使用率100%，可用空间为0，但用 du -sh / 把根目录从头到尾算一遍，却发现实际占用的空间远没那么多。这中间的差值去哪了？

根本原因是被进程占用的已删除文件，df统计文件系统级块使用量包含此类文件，du只遍历可见目录树故不计；可用sudo lsof +L1精准定位并重启对应服务释放空间。

简单来说，就是文件虽然被“删除”了，但某个或某些进程还紧紧攥着它的句柄不放。空间实际上被内核“暂扣”着，并没有真正释放回文件系统。所以，在Linux的世界里，删除文件并不总是等同于立刻释放空间，关键得看还有谁在用它。

lsof +L1：定位“幽灵文件”的唯一可靠入口

遇到这种情况，很多人的第一反应是去搜 lsof | grep deleted。但这里有个坑：这个命令会误匹配那些路径里恰好包含“deleted”字样的正常文件，比如 /tmp/deleted_cache/ 目录下的东西。这显然不是我们想找的目标。

真正专业的做法，是使用专为“链接计数为0”文件设计的过滤器：lsof +L1。这个选项能精准抓出那些已经被 unlink() 系统调用从目录树中移除，但文件描述符（fd）仍被进程打开着的“幽灵文件”。

具体操作时，有几个命令变体很实用：

• 全局扫描：sudo lsof +L1（普通用户权限看不到其他用户的句柄，所以sudo是必须的）
• 限定用户：sudo lsof -u www-data +L1（如果你怀疑是某个特定用户，比如Web服务用户）
• 限定挂载点（需谨慎）：sudo lsof +D /var/log +L1（注意，+D 选项会递归扫描目录，开销较大，通常只用于像 /var/log 这样明确怀疑的目录）

命令输出的结果里，有几个字段是关键：PID（进程ID）、FD（文件描述符，如 5w 表示5号描述符且为写入模式）、SIZE/OFF（当前占用的字节数，直接反映了“空间黑洞”的大小），以及标记 (deleted)（必须有这个标记，否则就不是我们要找的目标）。

为什么df和du的结果会差一大截？

这得从两者的统计原理说起。df 命令汇报的是文件系统级别的数据块使用情况，它从超级块中读取信息，所有被分配出去但尚未释放的块（包括那些已被删除但句柄未关闭的文件所占用的块）都会被计算在内。

而 du 命令则是老老实实地遍历目录树，统计每个可见文件的大小。对于那些已经从目录树中消失、仅存在于内核文件表里的“已删除文件”，du 自然就“看”不到了。

所以，df 和 du 的差值，大致就等于所有未被释放的句柄所对应的 SIZE/OFF 总和。有个快速估算总占用的命令可以参考：

sudo lsof +L1 2>/dev/null | awk '{sum += $7} END {printf "MB: %.0f\n", sum/1024/1024}'

如果这个差值达到了GB级别，那基本可以断定，是某个日志文件或者核心转储（dump）文件在后台疯狂增长，并且被某个进程持续写入。

需要提醒的是，在某些容器或chroot隔离环境下，lsof 的视角可能受限，不一定能看到全部的句柄。

释放空间时最常踩的三个坑

找到罪魁祸首的PID之后，是不是就该立刻 kill -9 了？且慢，冲动是魔鬼。先看清楚这个进程是什么来头：它是systemd管理的服务吗？杀掉它会不会有子进程继承文件描述符？它支持平滑重启（reload）吗？

这里有几个常见的操作误区：

1. 别直接上 kill -9：像nginx、rsyslog、Ja va应用这类程序，可能在强制终止时还在刷写缓冲区，粗暴地杀掉会导致日志丢失或触发非正常的退出流程。
2. 优先尝试信号重载：对于支持重载的进程，可以先发信号试试。例如，sudo kill -USR1 常用于nginx或logrotate风格的日志重切；sudo kill -HUP 则常用于rsyslog等进程的重启。
3. 清空 /proc//fd/ 要极度小心：通过 echo "" > /proc/1234/fd/5 的方式确实可以截断文件内容，但文件描述符依然保持可写状态。对于一些应用（比如某些数据库），文件长度的突然变化可能导致程序出错。

说到底，最安全、最标准的释放方式永远是：先确认该进程属于哪个系统服务（比如通过 systemctl status 查看），然后执行 systemctl restart 来优雅地重启服务。硬杀（kill -9）这种手段，最好留给无主进程或纯粹的调试场景。

另一种“假满”：inode耗尽

有时候，系统报错“No space left on device”，但 df -h 一看，明明还有20%的剩余空间。这很可能不是空间问题，而是inode（索引节点）耗尽了。inode是文件系统的元数据，用来存储文件的属性信息。文件数量爆炸式增长（比如海量小文件）就会吃光inode。

这时，用 df -i 命令查看，如果 IUse% 这一列显示100%，那就得立刻着手清理小文件了。

如何定位inode消耗大户？可以试试这个命令组合，它能快速找出目录树下小文件最密集的区域：

find /var -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -5

常见的inode“杀手”包括：/var/spool/postfix/maildrop/ 目录下堆积的待发邮件、/var/lib/docker/overlay2/ 里残留的悬空镜像层（dangling layer），以及某些应用临时目录下生成的大量空文件。

在清理之前，同样需要确认一下：这些海量小文件，是否也被某个进程打开后未关闭？前面提到的 lsof +L1 命令同样能暴露这类“已删除但fd仍持有”的空文件句柄。

真正棘手的情况，是那种既没有出现在 lsof +L1 列表里，df -i 也显示正常的案例。这大概率是因为容器内部的视角隔离——文件句柄被容器内的进程持有，在宿主机上用 lsof 看不到；或者，句柄被某些内核线程（如 kdump）持有，它们通常不可见。对于这类情况，就需要进入容器的命名空间（namespace）内部去排查，或者检查 /proc/mounts，看看是不是存在挂载覆盖导致了信息隐藏。