我的Nagios系统发给我一个警告，告诉我在我们的OS X服务器上的其中一个驱动器上的磁盘空间非常低。 当我运行df /Volumes/Apps/我得到
/dev/disk0s3 117209520 114932472 2277048 99% /Volumes/Apps
当我运行du -c /Volumes/Apps它会报告
11489944 total
为什么会有这么大的差别呢？ 更重要的是，我怎样才能find这个问题，我该怎么办呢？ 我基本上只是一个Windowspipe理员，所以我的舒适区在这里。 我使用Mac，但我不是真正意义上的Macpipe理员。
更新：
运行ls -laR /Volumes/Apps/报告总共10281584个，尽pipe处于相同的附近，但令人困惑的是甚至比du报告还要低。
修正：
一个解决方法，而不是一个解决scheme，这就是为什么它不被公布为答案。 我只是重新格式化应用程序分区，并恢复其内容。 在此之前，我确实运行了磁盘工具来尝试检测/修复任何问题，但报告没有发现问题。
这很奇怪。 df报告或我应该说的唯一的事情是考虑到du不是元数据。 正如这篇文章所解释的那样，由于du在用户空间中运行，因此du不计算inode，磁盘映射和超级块。
难道这可能是苹果在您的文件系统映射坏块，因此他们成为“使用”根据DF？ 由于这不会发生在用户空间，这将解释为什么杜不报告。
另外作为一个便笺，我敢肯定，你已经知道，DF和杜默认报告块计数使用，而不是大小。 因此，如果df或du报告总共117209520和您的块大小，如果512然后：
117209520 * .512 / 1024 = MB
如果你想看到它在人类可读的单位，只需使用df -h或du -sh
我相信你看到这个，因为du报告你请求的path下的目录的大小。 如果您在/ Volumes / Apps中有任何文件，IE将不会将其大小添加到计数中。
您可以通过执行以下操作来validation这一点：
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或其他单一文件的集合占用你的空间块。