我的 Nagios 系统向我发送了一条警报，通知我我们的 OS X 服务器上某个驱动器上的磁盘空间非常低。当我运行时， df /Volumes/Apps/我得到了
/dev/disk0s3 117209520 114932472 2277048 99% /Volumes/Apps
当我运行 du -c /Volumes/Apps它时报告
11489944 total
为什么会有如此巨大的差异？更重要的是，我如何找到问题所在，我能做些什么？我本质上只是一名 Windows 管理员，所以这已经超出了我的舒适区。我使用 Mac，但我并不是真正意义上的 Mac 管理员。
更新：
运行ls -laR /Volumes/Apps/报告总计 10281584，令人困惑的是，尽管在同一范围内，但它甚至比 du 报告的还要低。
已纠正：
这是一种解决方法，而不是解决方案，这就是为什么它没有作为答案发布的原因。我只是重新格式化了 Apps 分区并恢复了它的内容。在此之前，我确实运行了磁盘实用程序来尝试检测/修复任何问题，但它报告没有发现任何问题。
答案1
这很奇怪。df 报告的唯一内容（或者说应该说考虑了而 du 没有考虑的内容）是元数据。正如这由于 du 在用户空间中运行，因此文章 du 不计算 inode、磁盘映射和超级块等内容。
可能是因为 Mac 将坏块映射到文件系统中，因此根据 df，它们被“使用”了？由于这不会发生在用户空间中，因此可以解释为什么 du 不报告它。
另外需要说明的是，我相信您已经知道 df 和 du 默认报告的是块计数使用情况，而不是大小。因此，如果 df 或 du 报告总数为 117209520，并且您的块大小为 512，则：
117209520 * .512 / 1024 = MB
如果你想以人类可读的单位查看它，只需使用 df -h 或 du -sh
答案2
我相信您看到这个是因为 du 报告了您请求的路径下的目录大小。例如，如果您在 /Volumes/Apps 中有任何文件，它不会将其大小添加到计数中。
您可以通过执行以下操作来验证这一点：
touch /Volumes/Apps/test.txt
cat /dev/random > /Volumes/Apps/test.txt (control-c this after a sec to stop it)
du -c
此时请注意，当您运行 du 时它不会显示该文件。现在执行以下操作：
mkdir /Volumes/Apps/test
mv /Volumes/Apps/test.txt /Volumes/Apps/test/test.txt
du -c
您现在应该可以看到 test.txt 文件占用的空间。就您的情况而言，我假设您有一组 .dmg、zip 文件或其他占用大量空间的单片文件。