根本原因是被进程占用的已删除文件，df统计文件系统级块使用量包含此类文件，du只遍历可见目录树故不计；可用sudo lsof +l1精准定位并重启对应服务释放空间。
磁盘显示 100% 满，但 du -sh / 算出来远没那么多——八成是进程还攥着已删文件的句柄，空间卡在内核里没还回来。直接删文件不等于释放空间，得看谁还在用它。
lsof +L1 是唯一可靠入口
别信 lsof | grep deleted，它会误匹配路径含 deleted 字样的正常文件（比如 /tmp/deleted_cache/）。+L1 才是专为“链接计数为 0”设计的过滤器，只抓真正被 unlink() 但 fd 仍打开的文件。
- 全局扫描：
sudo lsof +L1（普通用户看不到其他用户的句柄） - 限定用户：
sudo lsof -u www-data +L1 - 限定挂载点（谨慎）：
sudo lsof +D /var/log +L1（+D递归扫描开销大，/var/log这种目录才考虑）
输出中关键字段：PID（进程 ID）、FD（如 5w 表示 5 号写入 fd）、SIZE/OFF（当前占用字节数，直接反映空间黑洞大小）、(deleted)（必须存在，否则不是目标）
为什么 df 和 du 结果差一大截？
df 统计的是文件系统级块使用量，包含所有已删但未关闭的文件所占空间；du 只遍历目录树下可见的文件，自然漏掉那些 (deleted) 条目。两者差值 ≈ 所有未释放句柄的 SIZE/OFF 总和。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 快速估算总占用：
sudo lsof +L1 2>/dev/null | awk '{sum += $7} END {printf "MB: %.0f\n", sum/1024/1024}' - 若差值达 GB 级，基本可断定是某日志或 dump 文件在后台疯长
- 注意：某些容器或 chroot 环境下，
lsof视角受限，可能看不到全部句柄
释放空间时最常踩的三个坑
看到 PID 就 kill -9？先看清楚它是不是 systemd 服务、有没有子进程继承 fd、是否支持平滑 reload。
- 别直接
kill -9：nginx、rsyslog、java 应用等可能正在刷缓冲区，强制杀会丢日志或触发异常退出 - 优先试信号重载：
sudo kill -USR1 <code>PID（nginx/logrotate 风格）、sudo kill -HUP <code>PID（rsyslog 风格） - 清空
/proc/<code>PID/fd/FD要极度小心：echo "" > /proc/1234/fd/5会截断内容但保持 fd 可写，部分应用（如数据库）可能因文件长度突变出错
真正安全的释放方式永远是：确认该进程属于哪个服务 → 查 systemctl status <code>SERVICE → 执行 systemctl restart <code>SERVICE。硬 kill 只留给无主进程或调试场景。
inode 耗尽也会报 “No space left on device”
这不是空间问题，是元数据资源枯竭。即使 df -h 显示还有 20% 空间，df -i 若显示 IUse% 为 100%，就得立刻查小文件：
- 定位高 inode 占用目录：
find /var -xdev -type f | cut -d/ -f1-4 | sort | uniq -c | sort -nr | head -5 - 常见元凶：
/var/spool/postfix/maildrop/堆积的待发邮件、/var/lib/docker/overlay2/的 dangling layer、应用临时目录下的空文件 - 清理前先确认：这些小文件是否被进程
open()后未close()？lsof +L1同样能暴露这类“已删但 fd 持有”的空文件句柄
真正难处理的，是那种既没出现在 lsof +L1、df -i 又正常的 case——大概率是容器内部视角隔离，或者内核线程（如 kdump）持有的不可见句柄，这时候得进容器 namespace 或查 /proc/mounts 看挂载覆盖了没。
