Linux中删除文件后空间未释放，是因为进程仍持有已删文件句柄；需用sudo lsof +L1定位，再通过重启进程、kill -HUP或echo > /proc/PID/fd/FD安全释放，预防推荐logrotate和truncate替代rm。
Linux 中删除文件后空间没释放，不是文件没删掉，而是进程还在用它——文件虽从目录里消失，但数据块仍被内核锁住。关键在找出谁“攥着”这些已删文件，再安全释放。
先确认是不是这个问题
运行两个命令对比：
- df -h：看分区整体使用率（比如 / 已用 95%）
- du -sh /* 2>/dev/null | sort -hr | head -5：统计根下各目录真实占用
如果 df 显示用了 20G，du 加起来才 14G，差的那几 GB 很可能就是被删未释的文件占的。
精准找出被占用的已删文件
别用 lsof | grep deleted —— 容易误匹配路径含 “deleted” 字样的正常文件。正确命令是：
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（如 7w）、SIZE/OFF 和最后一列带 (deleted) 的条目。
安全释放空间的两种方式
选哪种取决于业务能否中断：
-
重启或重载进程（推荐）：对支持平滑重载的服务，发 SIGHUP，例如
kill -HUP 1234；或用systemctl restart nginx。比强制 kill 更稳妥 -
不清退进程，只清空内容（需 root）：执行
echo > /proc/1234/fd/7（FD 号来自 lsof 输出的数字列）。文件立即变空，空间释放，进程还能继续写新内容，适合 nginx、Java 等长期服务
日常预防建议
避免反复踩坑：
- 别直接
rm正在写的日志文件，改用truncate -s 0 filename或> filename - 配置
logrotate，启用copytruncate或确保应用支持 SIGHUP 重开日志 - 加个简单监控：每天跑一次
sudo lsof +L1 2>/dev/null | wc -l，数量突增就预警
