the usual
inconsistent at best
OS X El Capitan and the case of the missing disk space

For several weeks I’ve had a 69 GB chunk of disk missing. No scanner could detect where it had gone (DaisyDisk, WhatSize, Finder, “About This Mac → Storage”, Disk Utility (also in Recovery mode), command-line utilities df and du): they all indicated that there was only 18G left and none of them could tell me where the missing 69G was.

I have an encrypted boot volume and thought that perhaps something had been corrupted, but I wasn’t sure. I haven’t ever seen anything like this before. I remembered fsck from my happy FreeBSD days, so I thought I would single-user boot and run an fsck_hfs to see what might come up, but first I needed to figure out which disk was the right one to scan; Disk Utility helped with that: select the primary volume (mine is the default “Macintosh HD”) and notice the “Device” in the bottom left corner: disk1

which device

Now after a single-user boot, I tried rebuilding the catalog file on /dev/rdisk1 (the raw device representing my encrypted hard drive volume) using fsck_hfs -Rc -y /dev/rdisk1 and it bailed out with an out of disk space error.

When I rebooted to try to free up some space, it took forever to come back up, but when it finally did, all the missing disk space was back and I now have 85G instead of 18G left.

For good measure, I single-user booted again and reran fsck_hfs:

second try

You can see how many times it tried to fix things. It finally came back clean. Just for paranoia, I ran it again and everything came back clean (except that odd warning afterward…I’m ignoring it):

third time’s a charm

Now the missing space is a reasonable 3.5G, and I am now led to believe that is, at least in part, the catalog file and other filesystem mapping files, which are inaccessible to user-space utilities.


I’m delighted because I was this close to shlepping my files off to a USB drive and reinstalling the OS.

Update: November 2018

This mysterious missing space bit me again recently. The options for fsck_hfs have changed, but it seems like this cause of hidden space is different than before.

I took a chance on the idea that Mac OS knows what’s going on and would fix it “just in time” for me, so I created a couple of big files:

$ dd if=/dev/random of=big-file1 bs=2048 count=1000
$ cat big-file1 >> big-file2
$ cat big-file2 >> big-file1

I repeated these two cp lines a few times until I was chewing up gigs of space. While doing this, I was paying attention to the output of df. At one point, I crossed a threshold and Mac OS reclaimed the missing space automatically so that I could continue using the disk. At this point I stopped and removed the big files. This gave me back roughly 50Gb (about 1/4 of my disk!).

I’d recommend this method first to anyone before going into single user mode.

Last modified on 2016-01-23