我有一个在 vSphere 集群中运行的 CentOS 7.2（最小）虚拟机，该虚拟机有一个 16G 驱动器，在 CentOS 安装程序的默认全磁盘使用分区方案下格式化为 XFS。系统正在运行测试httpd服务（所有软件都来自默认的centos存储库），但其磁盘空间使用量正在增长。这部分来自有问题的 apache 错误/访问日志（大小为 2+GB），删除这些长整型可以释放一些空间。我不太关心什么占用了驱动器空间（我最终会用核武器来解决这个问题）。但是，当我运行 df 和 du 来检查文件大小时，我得到了差异，这就是令人困惑的地方。
首先我运行df -h查看文件系统使用情况：
[root@svrhttp03 httpd]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos_svrhttp03-root 14G 4.8G 9.1G 35% /
devtmpfs 902M 0 902M 0% /dev
tmpfs 912M 0 912M 0% /dev/shm
tmpfs 912M 97M 816M 11% /run
tmpfs 912M 0 912M 0% /sys/fs/cgroup
/dev/sda1 497M 169M 329M 34% /boot
tmpfs 183M 0 183M 0% /run/user/0
这显示根 FS 上使用了 4.8G。
然后，我运行以下命令来查看文件系统根目录下所有项目的大小：
[root@svrhttp03 httpd]# du -a -h -t 10K / 2> /dev/null | grep -v -E "[A-Z,a-z,0-9]/." | sort -h
16K /home
7.4M /root
31M /etc
97M /run
143M /boot
324M /var
1.3G /usr
1.9G /
这显示仅使用了 1.9G，并且报告的所有目录大小加起来约为 1.9G，正如预期的那样。
df那么我怎样才能找到磁盘上数据的内容和du声明之间大约 2.9G 的差异呢？
答案1
这可能不是完整的答案，但我知道这种差异有两个来源：
df显示比du（又名不可能的大文件）更多的空间
稀疏文件可能会导致这种情况。例如：由于 VMWare 中的错误，许多虚拟机上的 /var/log/lastlog 被报告为难以置信的大（如 1.2 TB）。它实际上并没有那么大，它只是一个稀疏文件。处理就是忽略它们。 df总是比du实际可用磁盘空间更准确。
df显示的磁盘比du指示的更满（也称为占用磁盘空间的不可见文件）
造成这种情况的常见原因是删除了进程仍保持打开状态的文件。在升级之后和重新启动之前，通常会出现这种情况 - 所有旧的库文件仍然由具有文件句柄的进程保持打开状态，即使它们被“删除”并且不会从du或中显示ls。
最简单的处理方法是重新启动，但您可以更巧妙地处理它。例如，首先lsof | grep -c DEL查看有多少已删除的文件仍然打开。 （一定量是相对正常的，不一定是病态的，但它仍然是了解磁盘空间差异的正确位置。）
答案2
虽然通配符的答案是绝对正确的，但也许说出原因更有意义。
杜总结了文件大小递归地遍历指定路径中的所有文件虚拟FS其中可以包括多个已安装的文件系统。
df 报告已分配和未分配空间文件系统的。
为文件分配的空间并不总是与文件大小相同。大多数文件系统分配的块比一个字节大得多，因此文件在最坏的情况下可以分配整个块，然后只使用其中的一个字节。如此多的小文件将分配比它们大小总和更多的空间。进一步的稀疏文件可以具有比其分配的空间更大的文件大小，因为它仅分配文件的非零数据部分。