1

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.

Update:

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

Rectified:

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.

2 Answers 2

0

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

2
  • 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. May 27, 2010 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 Utility.app should suffice. May 27, 2010 at 15:07
0

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.

1
  • 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. May 27, 2010 at 3:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .