df 与 du 空间统计为什么不同：删除文件、挂载与稀疏文件
磁盘告警后运行 du，却找不到与 df 对应的大文件，直接继续删除常常没有帮助。Ubuntu 24.04 上，df 问的是文件系统的块使用情况，du 则遍历可见文件并累计空间。两者统计对象不同，只有先统一设备、路径、权限和单位，差异才有诊断价值。
先比较同一个文件系统
假设 /srv/data 是已确认的数据盘挂载点，在服务器执行：
findmnt -T /srv/data
df -B1 /srv/data
sudo du -x -B1 -s /srv/data
-B1 统一显示单位，du -x 避免跨到其他文件系统。使用管理员权限是为了减少无法进入目录造成的漏计，但也应读取命令报错，不能把带权限错误的结果当成完整总量。
如果只对文件系统中的一个子目录执行 du，却拿它与整块盘的 df 比较，本来就不应该相等。容器内外、绑定挂载和不同挂载命名空间也会影响可见范围。df 手册说明了它按所属文件系统报告空间的方式。
文件删除后仍可能没有释放
程序打开文件后，目录项被删除，数据可能继续由文件描述符引用。du 无法从原目录找到它，文件系统却仍然分配着空间。如果已安装 lsof，可由管理员用 sudo lsof +L1 查看链接数小于一的打开对象，再按设备和进程核对是否属于目标盘。
发现这类文件后，不要直接强杀进程或对描述符截断。先确认它是日志、临时文件还是数据库相关对象，再使用应用认可的重新打开、关闭或维护重启方式。释放后复查 df，同时确认应用没有丢失必要数据。
这一现象也解释了为什么“删除了十几个大日志，空间仍没回来”。删除动作改变名称，不一定立即结束所有引用。
挂载可能遮住旧目录内容
如果数据盘未挂载时，应用往挂载目录写过文件，之后再挂载数据盘，旧文件会被遮在底层文件系统里。当前 du 看到的是新挂载的内容，却看不到底层旧文件；原系统盘的 df 仍会统计它们。
确认这种情况需要清楚理解挂载结构。不要在生产业务仍使用数据盘时直接卸载，只为“看看下面有什么”。应安排停写和维护窗口，或由熟悉挂载命名空间的维护者通过受控方式只读检查。不要把底层文件误认为已经备份好的副本后直接清理。
稀疏文件与链接会改变直观判断
某些镜像或数据文件的逻辑长度很大，却没有为全部范围分配磁盘块。ls -l 常显示逻辑长度，du 默认更接近实际已分配空间；du --apparent-size 则采用另一种口径。两种结果不同不一定是文件损坏。
硬链接让多个名称引用同一个文件，简单把每个名称的大小相加会重复统计。写时复制与共享块文件系统还存在额外的空间分摊问题，不能拿普通文件总长度直接推算物理占用。du 手册介绍了实际占用、表观大小与链接统计选项。
因此，不要通过复制文件来验证“大小应该是多少”，复制过程本身可能改变稀疏布局或共享关系，并需要额外空间。
保留空间与文件系统元数据分开解释
文件系统元数据也占空间，目录遍历不一定会把它作为普通文件展示。ext4 的保留块还可能造成“总量减已用不等于普通用户可用”的差异；这与“已用块全都藏在某个目录里”不是同一个问题。
不要为了让三个数字对齐就立刻调整保留比例或执行文件系统修复。先确认文件系统类型、实际权限和告警口径，保留比例的变更需要结合系统盘与数据盘用途评估。
每处理一种原因后，重新用同一组命令采样，并记录业务是否继续写入。只有范围和时间都可比，数字变化才说明本次操作释放了什么。真正要恢复的是可用容量和可靠的数据状态，不是让两个本来不同口径的工具强行显示相同结果。