几乎可以确定是已删除但未释放的文件在占空间，或日志/缓存失控；应先用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，比事后抢救两小时更省事。
