df统计文件系统超级块元数据，du遍历目录累加可见文件块数；二者因统计口径不同常不一致，需结合lsof、-x、-i等参数协同排查。
df 和 du 看起来都在“查磁盘空间”，但它们根本不是一回事——一个看文件系统元数据，一个数目录里能看见的文件。用错场景、盲目对比结果，是运维中踩坑最多的地方。
df：快而宏观，专管“分区有没有爆”
df 读的是超级块（superblock）里的实时块统计，毫秒级返回，适合监控告警和快速判断。它不关心你删没删文件、目录里有什么，只认文件系统当前分配了多少块。
- -h 必加：避免手动换算 KB/MB/GB
- -T 查类型：ext4、xfs、overlay、tmpfs 行为差异大，比如 tmpfs 的“空间”实际是内存
- -i 同步看：Use% 没满但写不了文件？八成是 inode 耗尽，尤其在日志、容器、邮件目录下
- -x tmpfs -x devtmpfs 过滤伪文件系统：让输出聚焦真实存储设备，避免干扰判断
du：慢而细致，专找“谁吃了空间”
du 是真去目录里一个个读文件、累加占用块数。它看不到已被删除但进程还开着的文件，也容易被权限、挂载点、特殊文件系统带偏。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- -sh /path 先总览：-s 汇总、-h 可读，别一上来就 du / —— 太慢且易出错
- -x 锁定同一文件系统：比如查 /var，加 -x 防止误把挂载在 /var/lib/docker 下的 overlay2 卷也算进去
- --max-depth=1 分层定位：du -h --max-depth=1 /var | sort -hr，一眼看出哪个子目录是大户
- 慎用 * 展开：du -sh * 在含空格或特殊字符的目录名下会断裂；改用 find . -maxdepth 1 -mindepth 1 -print0 | xargs -0 du -sh
df 和 du 对不上？先别删文件，按顺序排查
差个几 GB 属正常；差几十 GB 或接近 100% 时，大概率是以下几种情况之一：
- 已删未释放的文件：lsof +L1 | grep -v "REG.*deleted" —— +L1 找链接数为 0 的打开文件，状态常标为 (deleted)
- 挂载点遮蔽：比如 /data 原来是本地目录，后来挂了 NFS；du /data 只看到 NFS 内容，df /data 却反映原分区状态
- 稀疏文件或保留块：ls -lh 显示 10G 的 qcow2 镜像，实际可能只占 2G 块；ext4 默认给 root 预留 5% 空间，普通用户 df 看似满了，root 还能写
- inode 耗尽：df -i 显示 IUse% 接近 100%，就得清理小文件，例如 find /var/log -name "*.log.*" -mtime +7 -delete
生产环境实用组合技
单靠一个命令解决不了问题，关键在链路闭环：
- 告警触发时：df -hT && df -iT 一起跑，5 秒内确认是块满还是 inode 满、是什么文件系统
- 定位大户：du -xhd1 /var | sort -hr | head -5，再对每个可疑目录重复 drill-down
- 清理前验证：du -sh /path/to/delete 确认大小，避免误删；删后执行 sync; echo 3 > /proc/sys/vm/drop_caches（非必需，但可辅助释放缓存视图）
- 长期监控：df -h >> /var/log/df-history.log 每小时记录，配合 gnuplot 或 Grafana 看趋势
