最常见原因是已删除文件仍被进程占用句柄，df统计占用而du不可见；需先执行df -h和df -i确认是否空间或inode耗尽，再用lsof +L1查找deleted文件，针对日志、journal、docker等高危目录清理并配置logrotate或journalctl自动限制。
磁盘显示已满但 du 统计不出来大文件，最常见原因是：文件已被删除，但进程仍在占用句柄，空间未释放。这不是“找不到”，而是它已不在目录树里，du 看不见，df 却还记着。
先确认是不是空间真满了
执行两条命令，一次看清两个维度：
- df -h：看 / 分区 Use% 是否达到 95% 或 100%
- df -ih：看同一行的 inode Use% ——如果这里满（比如 100%），而 Size 还有余量，说明是大量小文件耗尽了 inode，不是大文件问题
检查被删除但仍被占用的文件
这类文件在 df 里算“已用”，但在目录中不可见，du 自然统计不到。用下面任一命令查找：
- lsof +L1：直接列出所有链接数为 0 的打开文件（即已删但未释放）
- lsof / | awk '$5=="REG" && $11 ~ /deleted/ {print $1,$2,$9,$11}'：更精准过滤出被删的常规文件，显示进程名、PID、文件路径和状态
输出中带 (deleted) 标记的行就是元凶。SIZE/OFF 列数字就是它占着不放的空间大小。
定位高危目录快速筛查
即使没有“幽灵文件”，日志、缓存、容器层也常在后台悄悄膨胀。优先检查这些路径：
-
/var/log：尤其
catalina.out、journal、syslog——没配 logrotate 就容易失控 -
/var/log/journal：systemd-journald 默认不限大小，
journalctl --disk-usage可查实际用量 -
/var/lib/docker/overlay2：Docker 环境下，
docker system df比 du 更准，docker system prune -a可清理无用层 - /tmp 和 /var/tmp：临时文件可能残留大体积转储或备份包
释放空间的关键操作
找到问题进程后，别直接删文件或硬 kill，按类型处理：
- 日志类进程（rsyslog、nginx、apache）：用 reload 重载配置，让其关闭旧 fd、新建日志文件，空间立刻释放
- systemd-journald：运行 journalctl --vacuum-size=500M 清理旧日志，再改
/etc/systemd/journald.conf加上SystemMaxUse=500M防复发 - 无法 reload 的进程（如某些 Java 应用）：确认业务允许后，再 kill -9 PID；若属容器内进程，考虑 docker stop + rm
