删完大文件df -h仍显示满，大概率是文件被进程占用未释放；应先运行lsof +L1定位已删除但打开的文件，再根据进程类型选择reload、kill或truncate清理。
删完大文件，df -h 显示空间还是满的？大概率不是没删对，而是删了但没释放——进程还攥着文件句柄。先确认这点，再动手，否则白忙。
用 df -h 和 du -sh 对不上时，优先查 lsof +L1
当 df -h 显示根目录使用率 99%，但 du -sh /* 2>/dev/null | sort -hr 加起来才 60G，差值就是“已删未释放”的文件占着的 inode 和数据块。
-
lsof +L1直接列出所有链接数为 0（即已被rm删除）但仍被进程打开的文件 - 常见输出形如：
rsyslogd 1234 root 1w REG 253,1 1287454720 0 123456 /var/log/syslog (deleted) - 别急着
kill -9：对日志类服务，优先发kill -HUP 1234让它重开日志文件；或用truncate -s 0 /var/log/syslog清空内容（保留文件路径和句柄，不中断写入）
find 找大文件比 du -a 更快更准
要定位单个超大文件（比如暴增的 nohup.out、容器日志、core dump），find 按 size 过滤比 du -a 全盘扫描快得多，也避开了 /proc、/sys 等虚拟文件系统卡顿问题。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 全盘搜 >1G 的文件：
find / -xdev -type f -size +1G -ls 2>/dev/null | sort -k7 -hr | head -10（-xdev防止跨挂载点） - 只查日志目录：
find /var/log /home/docker /tmp -type f -name "*.log" -size +500M -ls 2>/dev/null - 注意
-size +100M中的单位：M 是 1024×1024 字节，c 表示字节，k 是 1024 字节，G 是 1024³ 字节
清理前必须确认的三件事
盲目 rm -f 可能导致服务崩溃或数据丢失。动手前快速核对：
- 文件是否正被进程写入？用
lsof /path/to/file查看有无 WRITE 句柄 - 是否是数据库 binlog、WAL 日志？比如 MySQL 的
mysql-bin.*或 PostgreSQL 的pg_wal/，直接删会破坏主从或崩溃实例 - 是否属于某个包管理器缓存？
/var/cache/apt/archives/（Debian）或/var/cache/yum/（RHEL）可安全apt-get clean或yum clean all
truncate -s 0 比 rm 更安全的日志清理方式
对正在滚动写入的日志文件（如 /var/log/messages、catalina.out），清空比删除更稳妥——不改变 inode，不触发进程重开文件逻辑异常。
-
truncate -s 0 /var/log/messages立即释放空间，且 rsyslog 会继续往同一文件写 - 等效但更慢：
echo "" > /var/log/messages（需确保 shell 有写权限） - 绝对避免：
rm /var/log/messages && touch /var/log/messages—— 新建文件的 inode 不同，旧进程仍往已删文件写，空间不释放，还可能丢日志
最常被跳过的一步是检查 df -i：小文件太多（比如千万级 session 文件、临时缓存）会导致 inodes 耗尽，此时 df -h 显示空间充足，却报 “No space left on device”。遇到这种诡异情况，先跑一遍 df -i，再筛 /tmp、/var/tmp、/var/lib/php/sessions 这类高 inode 消耗目录。
