Linux df 与 du 结果不一致的原因_网络技术_宿州市腾雀网络科技有限公司

df显示已用空间远大于du统计总和，因df统计文件系统级块使用（含元数据、预留空间、未释放的已删除文件），而du仅统计有硬链接且未被删除的文件内容块。

这是最常见现象，根本原因在于 df 读取的是文件系统级的块使用情况（含元数据、预留空间、未释放的已删除文件），而 du 只遍历当前目录下「有硬链接且未被删除」的文件内容块。两者统计口径不同，不是 bug，是设计使然。

典型诱因包括：

这类文件是导致 df 和 du 差值突增的首要怀疑对象。关键是找到那些状态为 deleted 但仍有进程打开的文件描述符。

执行以下命令：

lsof +L1 | grep -E 'DEL|deleted'

或更精准地按挂载点过滤（例如排查 /var）：

lsof +L1 /var 2>/dev/null | grep -v "No such process"

输出中会显示进程 PID、用户、文件路径（通常带 (deleted) 标记）。确认后可重启对应服务，或直接 kill 进程释放空间。

du 默认不进入其他挂载点（如 /proc、/sys、/boot 若为独立分区），也不统计不可读目录（权限不足时静默跳过）。这会让结果看起来比 df 小很多，但其实

只是没扫全。

检查是否遗漏挂载点：

findmnt -D /

重新运行 du 时加参数确保覆盖：

注意：du 对软链接默认不跟随，若需统计目标文件，加 -L；但生产环境慎用，可能引发循环引用或跨挂载点误入。

以 ext4 为例，df 报告的 “Used” 包含 root 预留块（通常是总空间 5%），即使普通用户磁盘已满，root 仍能写入。这部分空间对 du 完全不可见，但会拉高 df 的已用比例。

查看预留比例：

tune2fs -l /dev/sda1 | grep "Reserved block count"

调整（仅限必要时，且需 unmount 或只读 remount）：

tune2fs -m 1 /dev/sda1

xfs 无固定百分比预留，但有 mkfs.xfs -m rtextsize= 等元数据相关保留，且 xfs_info 输出中的 data 段会显示实际可用块数，df 与其一致，du 仍只算文件内容。

真正容易被忽略的是：哪怕你把预留调成 0，只要存在未清理的 deleted 文件、快照（LVM/btrfs）、或 journal 日志膨胀，df 和 du 的差值依然存在——得回到 lsof +L1 和 journalctl --disk-usage 这类具体工具去查。