Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My Nagios system sent me an alert to inform me that the disk space on one of the drives on our OS X server is very low. When I run df /Volumes/Apps/ I get

/dev/disk0s3  117209520 114932472   2277048    99%    /Volumes/Apps

When I run du -c /Volumes/Apps it reports

11489944        total

Why might there be such a vast difference? Even more importantly, how do I find the problem and what can I do about it? I'm essentially just a Windows admin, so am well out of my comfort zone here. I use a Mac but I'm not a Mac admin in any real sense of the word.


Running ls -laR /Volumes/Apps/ reports a total of 10281584, which confusingly is even lower than du reports, although in the same vicinity.


A workaround, not a solution, which is why it's not posted as an answer. I simply reformatted the Apps partition and restored it's contents. Prior to that I did run Disk Utility to try and detect/repair any problems but it reported no problems found.

share|improve this question
up vote 0 down vote accepted

This is strange. The only thing that df reports or should I say takes into account that du does not is metadata. As explained by this article du does not count things like inodes, disk maps, and super blocks since du operate in userspace.

Could it perhaps be the Mac mapping bad blocks out in your filesystem and thus them becoming "used" according to df? Since this would not happen in userspace it would explain why du does not report it.

Also as a side note and I'm sure you know already that df and du by default report block count usage, not size. Therefore if df or du report a total of 117209520 and your block size if 512 then:

117209520 * .512 / 1024 = MB

If you'd like to see it in human readable units just use df -h or du -sh

share|improve this answer
You're right, it is weird and I do think something has screwed up, but what and how do I fix it? Thanks for the extra info on du. – John Gardeniers May 27 '10 at 5:41
Well if you're getting bad blocks on your hard drive there's really no way to "fix" it other than replace the hard drive. Can you disk check on the drive to see if it has any problems? Either fsck or Disk should suffice. – Jordan Eunson May 27 '10 at 15:07

I believe you are seeing this because du reports the sizes of directories under the path you're requesting. IE if you have any files in /Volumes/Apps it won't be adding their size to the count.

You can verify this by doing the following:

touch /Volumes/Apps/test.txt
cat /dev/random > /Volumes/Apps/test.txt (control-c this after a sec to stop it)
du -c

At this point note that when you run du it won't show that file. Now do the following:

mkdir /Volumes/Apps/test
mv /Volumes/Apps/test.txt /Volumes/Apps/test/test.txt
du -c

You should now see the space being used by the test.txt file. In your situation I'm assuming you have a collection of .dmg's, zips, or other monolithic files taking up chunks of your space.

share|improve this answer
I did as you suggested and even run du after moving all the files in Apps (you're correct about those) into a sub-directory. The total is the same either way. i.e. The file size is counted whether it's in Apps itself or in a sub-directory. It was worth a try though. Thanks. – John Gardeniers May 27 '10 at 3:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.