df显示已用空间远大于du总和，主因是df统计文件系统级已分配块（含已删未释文件、保留空间等），而du仅统计仍有硬链接的文件内容块。
df 显示已用空间远大于 du 统计总和
这是最常见现象，根本原因在于 df 统计的是文件系统级的已分配块（包括被删除但未释放的文件、保留空间、元数据开销等），而 du 只遍历当前目录树下「仍被硬链接引用」的文件内容块。当进程仍在读写一个已被 rm 删除的文件时，该文件的磁盘块不会被 du 计入（路径已消失），但 df 仍将其算作“已用”。
- 运行
lsof +L1查看所有处于 unlink 状态但仍被进程打开的文件（即“幽灵文件”） - 确认后可重启对应进程，或直接 kill -HUP 其 PID 促使释放
-
du默认不统计硬链接重复计数，而df不关心链接关系，只看块是否被标记为已用
du 忽略挂载点子目录导致统计偏小
如果目标路径下存在其他文件系统挂载点（如 /mnt/data 是独立挂载的 ext4 分区），du 默认不会递归进入这些挂载点——它把它们当作普通目录，但实际内容在另一套 inode 和块管理中。此时 du 结果必然小于 df 报告的根分区使用量。
- 加
-x参数让du跨文件系统时跳过（默认行为），加--all无帮助，关键是用-x的反向逻辑：去掉它才能跨挂载点统计 - 更稳妥的做法是分别对每个挂载点单独运行
du -sh /path/to/mount - 用
findmnt或mount | grep " / "快速识别嵌套挂载
ext4 的 reserved blocks 和 df 的计算偏差
ext2/3/4 默认预留 5% 的块给 root 用户，防止系统因磁盘满而崩溃。这部分空间在 df 输出中计入“Available”，但不计入“Used”，却会影响总量计算逻辑；更重要的是，df 展示的 “Size” 是总块数减去 reserved，而 du 完全不感知 reserved 概念——它只管“哪些块正在被文件占用”。所以即使没有幽灵文件、也没有嵌套挂载，两者数值仍有固定偏差。
- 查看预留比例：
tune2fs -l /dev/sdXN | grep "Reserved block count" - 临时调低（仅限非系统分区）：
tune2fs -m 1 /dev/sdXN，设为 0 风险极高，不建议 - 这个偏差通常只影响百分比精度，不影响判断是否真满
权限不足导致 du 漏统计部分目录
du 是用户态命令，遇到无读取权限的目录（如 /root、某些容器卷挂载点）会跳过，静默忽略，不报错也不提示。而 df 是内核接口直读 superblock，完全不受用户权限限制。结果就是 du 总和明显偏小，且找不到明显原因。
- 加
2>/dev/null会掩盖问题，调试时务必先去掉重定向，观察 stderr 输出 - 用
sudo du -sh /可绕过权限限制，但要注意sudo下的环境变量和 PATH 可能影响某些脚本行为 - 容器场景中，
du在宿主机执行可能无法访问容器内部挂载的 tmpfs 或 overlay2 层，需进容器 namespace 才准
du 当成磁盘真实占用证据，或者看到 df 显示 98% 就立刻 panic 却没查 lsof +L1 ——很多“磁盘满”的故障，其实只是日志文件被删没关进程。 
