Linux删除文件后空间未释放，是因为进程仍持有已删文件的句柄；用df与du对比可发现差异，再执行sudo lsof +L1精准定位被占用的(deleted)文件，推荐通过kill -HUP PID或echo > /proc/PID/fd/FD清空释放空间。
Linux 中删除文件后磁盘空间没释放，不是文件没删掉，而是进程还攥着它的句柄——文件虽从目录里消失，但数据块仍被占用。lsof 是唯一能“看见”这些幽灵文件的工具。
确认问题是否存在
先看 df 和 du 是否对不上：
- 运行 df -h 查总空间使用率（比如显示 / 已用 98%）
- 再运行 du -sh /* 2>/dev/null | sort -h 统计各目录真实大小
- 如果两者差值明显（例如 df 显示用了 20G，du 加起来才 12G），差的那部分大概率就是被删未释的文件占的
精准定位被删但仍在用的文件
别用 lsof | grep deleted ——容易误匹配路径含 deleted 字样的正常文件（如 /tmp/deleted_cache）。正确命令是：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- sudo lsof +L1：只列出链接计数为 0 的打开文件，即真正被 unlink 但 fd 仍活跃的文件
- 加限定更高效：sudo lsof +L1 /var/log（查日志目录）、sudo lsof -u root +L1（查 root 用户）
- 输出中重点看：PID（进程号）、COMMAND（进程名）、FD（如 1w 表示写入描述符）、SIZE/OFF（当前占用字节数）、最后一列带 (deleted)
判断实际影响和空间占用
光看到 (deleted) 不够，得确认它到底吃多少空间：
- 用 ls -lh /proc/PID/fd/FD号（例如 ls -lh /proc/1234/fd/1），看是否指向真实大小（如 3.2G）还是 /dev/null
- 或直接统计：du -sh /proc/PID/fd/FD号
- 快速估算所有已删文件总大小：sudo lsof +L1 2>/dev/null | awk '{sum += $7} END {printf "MB: %.0f\n", sum/1024/1024}'
安全释放空间的实操方法
不推荐直接 kill -9，优先选影响最小的方式：
- 发重载信号（推荐）：多数日志服务支持 SIGHUP，执行 kill -HUP PID，进程会关闭旧 fd、新建日志文件，原空间自动回收
- 清空 fd 内容（应急用）：执行 echo > /proc/PID/fd/FD号（需 root 权限），立即释放空间且进程不中断；注意这会丢掉当前缓冲中的日志内容
- 重启服务（稳妥但有停机）：如 systemctl restart rsyslog 或 systemctl restart nginx
预防比抢救更重要
这类问题 90% 出在日志上，靠手动 rm 治标不治本：
- 配置 logrotate，启用 copytruncate 或配合 postrotate kill -USR1 PID
- 检查 Java 应用是否用 Logback 的 RollingFileAppender，Nginx 是否配置了 log_format + reopen
- 监控脚本中不要只盯 df，应定期跑 sudo lsof +L1 | wc -l，数量突增即告警
