几乎可以确定是已删除但未释放的文件在占空间，或日志/缓存失控；应先用lsof +l1或lsof | grep deleted定位被进程占用的已删文件，再通过truncate -s 0或kill -hup安全释放，而非盲目rm -rf。

磁盘告警时，df -h 显示空间已满，但 du -sh * 统计总和远小于 df 的 Used 值——这几乎可以确定是“已删除但未释放”的文件在占着空间，或日志/缓存失控。别急着 rm -rf，先找准根因再动手。

怎么快速定位占用最大的文件（不是目录）

用 find 比 du 更准、更快，尤其适合找单个超大文件（比如滚动暴增的容器日志、nohup.out、core dump）：

• find / -type f -size +1G -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr | head -20：从根开始搜大于 1G 的文件，按大小倒序排前 20
• 若明确怀疑日志，加路径限制提速：find /var/log /home/docker /tmp -type f -name "*.log" -size +500M -ls 2>/dev/null
• 注意 2>/dev/null 屏蔽权限拒绝报错，否则输出会被干扰
• 避免用 du -a 全盘扫：它会递归进每个子目录，遇到挂载点（如 /proc、/sys）可能卡住或报错

为什么删了大文件，df 空间还不释放

这是最常被忽略的坑：文件被进程打开后删除，只是 unlink 了目录项，但 inode 和数据块仍被进程持有，空间不会归还。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 查证命令：lsof +L1（只显示已删除但仍被打开的文件）；或 lsof | grep deleted
• 典型场景：Tomcat、Nginx、Docker 容器持续写日志，日志轮转后旧文件被 mv 或 rm，但服务没重启，句柄未关闭
• 安全释放方式（不中断服务）：truncate -s 0 /path/to/deleted-but-still-open.log —— 清空内容，保留文件描述符
• 硬性释放方式（需评估影响）：kill -HUP <pid></pid>（重载日志）、或 kill <pid></pid>（终止进程）

du 和 df 结果对不上，除了已删文件还有啥原因

差值 ≠ 都是“隐藏文件”，得逐项排除：

• df -i 查 inode：小文件过多（如缓存、session）可能导致 Inodes 耗尽，df 显示“空间有余”但实际无法创建新文件
• tune2fs -l /dev/vda1 | grep "Reserved block count"：ext4 默认为 root 预留 5% 空间（df 的 Avail 已扣除），普通用户看不到这部分，但 du 不统计它
• mount | grep " / " 看是否被重新挂载为 ro（只读），此时写入失败也会报 “No space left on device”
• 检查配额：quota -u $USER 或 repquota -a，用户/组级磁盘配额可能已满

清理前必须确认的三件事

盲目删文件可能让系统瘫痪，尤其在生产环境：

• 确认目标路径是否属于当前分区：df /var/log，别在 /var/log 看到 95% 就冲进去删，结果发现 /var 是独立挂载的，而根分区其实还有余量
• 确认日志文件是否正在被写入：lsof +D /var/log，如果 rsyslogd 或 journalctl 正在写，直接 rm 可能导致服务异常
• 别碰 /proc、/sys、/dev 下的任何“文件”——它们是内核接口，不是真实磁盘文件，删了也没用，还可能触发 panic

真正棘手的从来不是“怎么删”，而是“删完会不会让某个服务突然哑火”。每次清理前花 30 秒看一眼 lsof 和 df -i，比事后抢救两小时更省事。