![OS X Server(Leopard)上的磁盘空间不匹配](https://linux22.com/image/514658/OS%20X%20Server%EF%BC%88Leopard%EF%BC%89%E4%B8%8A%E7%9A%84%E7%A3%81%E7%9B%98%E7%A9%BA%E9%97%B4%E4%B8%8D%E5%8C%B9%E9%85%8D.png)
我的 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 文件或其他占用大量空间的单片文件。