是，因为文件被进程持续占用时，rm仅解除目录链接，inode和数据块仍被锁定，df统计磁盘块占用故不释放，而du无法遍历已删路径导致差值。
已删除但进程仍在写入的文件，df 显示空间未释放？这是真占着
Linux 中文件被 rm 删除后，如果仍有进程以 O_RDWR 或 O_WRONLY 方式打开它（比如日志轮转时旧进程没退出），该文件的 inode 不会被真正回收，磁盘空间也不会释放——df 会继续统计这部分空间，但 du 找不到对应路径，造成“磁盘满但查不到大文件”的典型假象。
- 这类文件在
/proc/[pid]/fd/下能看到符号链接，目标是deleted（如ls -l /proc/1234/fd/5→/var/log/app.log (deleted)） -
lsof +L1是最直接的筛选命令，只列出已链接数为 0 但仍被打开的文件 - 注意：不是所有
deleted条目都占大量空间，得结合lsof -n -P -o -s | grep deleted看偏移量（OFFSET列近似文件大小）
lsof +L1 输出看不懂？关键字段含义和过滤技巧
lsof +L1 默认输出包含 CWD、FD、TYPE、SIZE/OFF、NODE、NAME 等列，其中真正反映占用的是 SIZE/OFF（对普通文件是字节数，对管道/套接字是 0）和 NAME 后缀的 (deleted)。
- 加
-s参数可显示文件大小（需 root 权限），否则SIZE/OFF可能只是当前读写位置 - 按大小倒序看：
lsof +L1 -s | sort -k7,7nr | head -20（第 7 列通常是SIZE/OFF） - 只看某用户或某路径下的残留：
lsof +L1 -u username或lsof +L1 /var/log - 某些容器环境里，
+L1可能漏掉，改用lsof -n -P | grep 'deleted$'更稳妥
找到进程了，但不敢杀？先确认是否可安全重启
看到 lsof +L1 列出的 PID 和 COMMAND 后，别急着 kill -9。很多服务（如 rsyslog、java 应用、nginx worker）在日志 reopen 前会持续写入已删除文件，强制 kill 可能导致数据丢失或服务异常。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 优先尝试平滑重载：
systemctl reload rsyslog、nginx -s reopen、kill -USR1 [pid]（对支持该信号的程序） - 检查进程是否属于容器：
cat /proc/[pid]/cgroup看是否有docker或kubepods字样；若是，应进容器内操作或重启 Pod - 临时释放空间但不中断服务：用
truncate -s 0 /proc/[pid]/fd/[fd_num]（仅适用于可 seek 的文件，且部分内核版本不支持）
为什么 du -sh /* 没用？因为已删文件根本不挂载在任何目录下
du 统计的是目录树中所有**硬链接存在**的文件大小，而已删除文件的路径已从文件系统目录结构中剥离，只剩内核中打开的 fd 引用。所以 du 完全看不见它们，df 却如实报告块占用——这不是 bug，是 Unix 文件模型的正常行为。
- 验证方法：对比
df -h /和du -sh / 2>/dev/null | grep -E '^[0-9]+'，差值明显且lsof +L1有输出，基本可锁定 - 不要依赖
find / -xdev -size +100M，它也找不到已删文件 - 监控建议：在关键路径部署
inotifywait或定期跑lsof +L1 | wc -l告警，比等磁盘爆了再救更主动
真正难处理的不是怎么查，而是判断哪个 (deleted) 是业务关键日志、哪个是临时缓存；有时候 lsof 列出几十个，但只有两三个实际占 GB 级空间——得盯住 SIZE/OFF 和进程生命周期，而不是盲目清理。
