df -h 是默认起点，因它自动换算单位、过滤虚拟文件系统，避免人工误差；Use% >100%是root预留空间所致；df -i 查inode；df /path精准定位挂载点；df与du差异揭示删除未释放或硬链接问题。
直接看结果，用 df -h 就够了；但如果你发现“已用 102%”或某目录明明没写多少东西却报“no space left on device”，那得继续往下查 inode 或挂载点偏差。
为什么 df -h 是默认起点
它把原始的 KB 单位自动换算成 MB/GB/TB，避免人工心算出错，且对齐人类直觉。默认只显示已挂载的本地文件系统，过滤掉 tmpfs、devtmpfs 等虚拟内存文件系统，减少干扰。
-
df不加参数时单位是 1K-blocks，数字大、难读，比如123456789你得自己除以 1024² 才知道是约 115G -
-h和-H都能“人性化”，但-h按 1024 进制（标准二进制单位），-H按 1000 进制（SI 单位），硬盘厂商标称容量常用后者，系统内部计算用前者——混用可能造成“标称 1TB 实际只看到 931G”的困惑 - 不推荐长期依赖
df -k或df -m：它们强制固定单位，反而掩盖真实量级差异，比如一个 512MB 分区在-m下显示为512，而另一个 4.2TB 分区也只显示4200000，无法一眼判断数量级
df 显示 “Use% > 100%” 是什么情况
这不是 bug，是 Linux 为 root 用户保留空间的设计所致。默认 ext4/xfs 文件系统会预留 5%（部分发行版设为 10%）空间给超级用户，防止普通用户写满后系统无法记录日志、无法 ssh 登录等。
- 执行
df -i看 inode 使用率，如果Use%接近 100%，即使磁盘还有几十 GB 剩余，也会报No space left on device - 执行
sudo tune2fs -l /dev/sda1 | grep "Reserved block count"可查当前预留比例；调整需谨慎：sudo tune2fs -m 1 /dev/sda1把预留降到 1%，仅建议用于大容量数据盘 -
df统计的是块设备层面的已用/可用，不反映文件删除后是否被进程持续占用（即“deleted but still open”状态），此时需配合lsof +L1查找残留句柄
如何精准定位某个目录所在的文件系统
df 默认显示所有挂载点，但你想知道 /var/log 到底跑在哪个物理分区上？不能靠猜路径层级，得让 df 主动解析挂载关系。
- 直接运行
df /var/log，它会自动向上追溯到该路径所属的最接近挂载点（比如输出/dev/sda2挂载在/，说明/var/log就在根分区） - 若路径本身是独立挂载点（如
/home单独挂了/dev/sdb1），df /home会明确显示该设备，而非根分区 - 避免用
df .在子目录中执行：当前工作目录可能被 bind mount 或 overlayfs 覆盖，导致结果与预期不符；优先用绝对路径 - 想排除临时文件系统干扰，加
-x tmpfs -x devtmpfs，例如df -h -x tmpfs -x devtmpfs
对比 df 和 du 的关键差异点
df 看的是文件系统级总账，du 算的是目录树里实际文件加起来的体积。两者结果不一致，往往意味着有隐藏问题。
- 若
df -h显示已用 95%，但du -sh /* 2>/dev/null | sort -hr | head -5加起来才 70G，大概率存在被删除但仍被进程打开的大文件（常见于日志轮转失败场景） -
du默认不统计硬链接重复计数，df完全不关心链接，只认块占用；所以大量硬链接不会让df数值变大，但会让du显示偏高 -
du --apparent-size会按文件逻辑大小（而非磁盘实际占用块）统计，对稀疏文件（如 qemu 镜像）更准确；而df始终按实际分配块计算
真正麻烦的不是命令记不住，而是看到 Use% 逼近 100% 时，下意识 rm -rf 清日志，却忘了先 df -i 看 inode，或者没意识到 /var/log/journal 被 systemd-journald 占着不放——这些细节不检查，删完照样报错。
