df -h仅显示挂载点剩余空间，需用du -sh组合筛选定位具体大文件或目录，如du -sh /var/log/* | sort -hr查日志中最大项，并注意df与du差异源于统计层面不同（文件系统块vs目录树）。

直接看 df -h 只能知道“哪个挂载点剩多少”，但没法告诉你“/var/log 里哪个日志文件占了 20G”——要查具体分布，必须组合 du 和筛选手段。

用 du -sh 快速定位大目录

这是最常用也最容易被忽略的第一步。du 统计的是目录实际占用的磁盘空间（含子目录），不是文件大小总和（比如硬链接、稀疏文件会影响结果）。

• du -sh /var/*：列出 /var 下一级所有目录的总大小，单位自动换算
• du -sh /home/* | sort -hr | head -10：按大小倒序排，取前 10 个最大项
• 别漏掉隐藏目录：du -sh /root/.* /root/* 2>/dev/null | sort -hr（2>/dev/null 屏蔽权限错误）
• 注意：du 默认统计的是“已分配块”，所以一个 1MB 的文件如果只写了 1KB 但分配了整块，也会算作 4KB（取决于文件系统块大小）

du -ah + sort -h 找出单个大文件

当怀疑是某个具体文件撑爆磁盘时，这招最直接。但要注意性能开销——遍历整个 / 很慢，建议限定路径。

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• du -ah /var/log | sort -h | tail -20：查 /var/log 下最大的 20 个文件（含子目录里的）
• du -ah /tmp | grep 'G\|M$' | sort -h：只显示 GB/MB 级别的条目，避免被 KB 条目淹没
• 常见陷阱：du 不会进入其他挂载点（比如 /proc、/sys），但如果你加了 -x 参数（du -ahx /），它就真的只查根文件系统，不会跨挂载点——这点常被误用

为什么 df 和 du 结果不一致？

这不是 bug，而是底层机制差异导致的常见困惑，直接影响你判断“空间到底去哪了”。

• df 读取文件系统超级块，反映的是整个分区的已用/可用块数
• du 遍历目录树，统计每个文件实际占用的数据块
• 典型不一致场景：
  • 有进程正在写一个大文件，然后被 rm 删除了——文件没真正释放，df 显示已用空间没变，但 du 已经看不见它了
  • 文件系统保留了 5% 的空间给 root（ext4 默认），df 的 “Available” 会扣掉这部分，du 不体现
  • 存在硬链接或 reflink（如 btrfs），同一数据块被多个路径引用，du 默认只算一次，df 看的是块总数

配合 lsof + deleted 检查“消失却占空间”的文件

当 df 显示空间已满但 du 加起来远小于该值，大概率是有被删除但仍被进程打开的文件。

• lsof +L1：列出所有 link count = 0 的打开文件（即已被 rm 但未关闭的）
• lsof -nP | grep deleted | head -10：快速筛出前十条，看 PID 和文件路径
• 确认后可 kill 对应进程，或让其主动 close 文件句柄——别直接 echo > /proc/PID/fd/N 清空，可能破坏应用逻辑
• 注意：lsof 需要 root 权限才能看到所有进程，普通用户只能看到自己的

真正难的不是命令本身，而是理解 df 和 du 分别在哪个层面工作；很多“空间莫名消失”的问题，其实只是你没意识到内核、文件系统、进程三者对“空间”的定义根本不同。