Linux 磁盘占用为何与目录统计不符:用 lsof 定位 deleted 文件句柄
遇到 df -h 显示根分区快满、du 加起来却少一大截时,先不要继续删除目录。最常见的原因是:文件名已经被 unlink,目录树看不到它,但进程仍持有文件描述符,文件占用的块要等最后一个句柄关闭后才释放。排查重点是把“文件系统统计”和“进程句柄”放到同一条证据链里。
先确认两个命令针对同一挂载点,再用 lsof +L1 找 deleted 文件;确认进程后,优先让服务正常重开日志或重启,空间通常会在句柄关闭后回落。
先固定挂载点:df 和 du 为什么看起来不一致
df 报告的是文件系统层面的已用和可用空间,du 则从目录层估算一组文件占用。两者统计对象不同,所以不要求数值完全相等。先执行:
df -hT /
du -xhd1 / 2>/dev/null | sort -h
df -ih /
-T 便于确认文件系统类型,du -x 不跨到其他文件系统,df -i 则排除“块没满但 inode 已耗尽”的另一类故障。如果 du 只统计了某个子目录,而 df 统计的是整个挂载点,差值也没有排障意义。

找出仍占空间的进程句柄
确认挂载点一致后,优先使用 lsof 做全局搜索:
sudo lsof +L1
sudo lsof -nP +L1 | sort -k7 -n
输出里的 COMMAND、PID、FD、SIZE/OFF 和 NAME 是关键线索。NAME 常会出现 (deleted);先按大小筛选,再检查它是否落在目标挂载点。若没有 lsof,可从进程目录确认:
sudo ls -l /proc//fd | grep deleted
sudo readlink /proc//fd/
Linux 的 /proc/ 为进程打开的每个文件描述符提供符号链接,因此这里看到的 deleted 不是一个可直接在目录中再次找到的普通文件,而是进程仍然握着的 inode。权限不足时,普通账号可能看不全其他用户进程的句柄。

确认候选后再决定怎么回收
不要看到 (deleted) 就直接对 fd 执行写入或关闭。先用 ps -fp 、服务单元状态和挂载点信息确认它属于哪个服务;还要留意容器、tmpfs、日志代理和权限隔离造成的“看见了进程、却对不上磁盘”的情况。
最稳妥的动作是按服务文档执行日志 reopen,例如发送服务支持的 reload 信号,或在维护窗口重启服务:
sudo systemctl reload your-service
# 若服务不支持安全 reopen,再评估:
sudo systemctl restart your-service
df -hT /
只有明确知道程序状态、fd 用途和数据风险时,才考虑对单个描述符做关闭操作;生产环境不建议把 > /proc/ 当作通用清理命令,它可能截断仍在使用的文件或让应用进入异常状态。
排障结果怎么判断
若服务重开文件后 df 的 Used 回落,且 du 与实际目录规模接近,基本可以确认是已删除但仍打开的文件。若没有回落,继续核对候选文件所在设备、inode 使用率、隐藏挂载点、快照或写时复制文件系统;不要把所有 df/du 差值都归咎于 deleted 句柄。
速查:df 看文件系统,du 看目录树;lsof +L1 看链接数小于 1 的打开文件;/proc/ 看进程句柄;回收优先走服务自身的 reopen 或受控重启。
相关问题
为什么删除大日志后空间没有立即回来?只要仍有进程持有该文件描述符,inode 和数据块仍在使用,最后一个句柄关闭后才会释放。
lsof 没有输出是不是就排除了句柄问题?不一定。权限、容器命名空间、挂载点选择和工具缺失都可能影响结果,应结合 root 权限、目标设备和 /proc 逐项确认。