Several Mac users have contacted me to report apparent contradictions between different estimates of free space remaining on their disks, particularly the startup volume.
In Sierra, these have mainly been discrepancies between figures claimed in the Storage tab of About This Mac, and everything else. In versions prior to 10.12.6, there were several bugs in that tab, which on many Macs never completed its calculations either. These were essentially fixed by 10.12.6, although even there completion can take a long time.
In High Sierra, some users have reported discrepancies of hundreds of GB, which go beyond minor computational error. The ways in which used and free space are reported have also become more complex, and in APFS there are now containers as well as volumes.
To look at this more carefully, I have adopted the recommended macOS system calls to obtain information about mounted volumes, through URL resource values. I will provide full source code in another article, but the algorithm involves:
- Obtain a URL for the path to each volume currently mounted in /Volumes.
- Obtain the resource values for each URL using calls of the form
let theRes = try theURL.resourceValues(forKeys: [.volumeAvailableCapacityKey, .volumeTotalCapacityKey])
let theCap = theRes.volumeAvailableCapacity
which returns the available capacity of the volume in bytes.
- Calculate the capacity used as the difference between the total and available capacities.
This is made more complex in High Sierra, because there are two additional resource values offered,
volumeAvailableCapacityForOpportunisticUsage, whose names are the best available guide as to what they might mean.
I have wrapped that code into a simple app named VolSizes, which runs on El Capitan (I hope), Sierra, and High Sierra. A copy, without any documentation, is available from here: VolSizes
Comparing the results obtained from VolSizes with those in standard GUI tools bundled with macOS Sierra, there are only two discrepancies which I have been able to identify.
The first is that the Finder’s Get Info dialog reports used capacities which are consistently slightly greater than those of VolSizes. The difference here appears to match the capacity designated by Disk Utility as being ‘purgeable’, typically a few GB. The second discrepancy occurs in the Storage tab, which consistently adds the ‘purgeable’ capacity to make the free capacity larger by a few GB.
As far as I can see, in normal conditions, Sierra’s remaining discrepancies are due to inconsistencies in the definition of free space between different parts of macOS, and the underlying figures appear to be consistent and reliable.
High Sierra 10.13.3
The system calls in High Sierra now provide three separate and quite different estimates of free capacity:
- volumeAvailableCapacity, which is common to previous versions of macOS;
- volumeAvailableCapacityForImportantUsage, which is new in 10.13;
- volumeAvailableCapacityForOpportunisticUsage, which is also new in 10.13.
Apple’s sole guidance on which of those to choose in High Sierra reads:
The query type to use depends on what’s being stored. If you’re storing data based on a user request or resources the app requires to function properly (for example, a video the user is about to watch or resources that are needed for the next level in a game), query against volumeAvailableCapacityForImportantUsageKey. However, if you’re downloading data in a more predictive manner (for example, downloading a newly available episode of a TV series that the user has been watching recently), query against volumeAvailableCapacityForOpportunisticUsageKey.
That doesn’t explain why those and the older volumeAvailableCapacity should differ, although one potential explanation might be whether using the higher capacity might require purgeable capacity to be emptied. As an example, reported values from VolSizes, converted to GB, might be:
- volumeAvailableCapacity 434.689 GB
- volumeAvailableCapacityForImportantUsage 436.388 GB
- volumeAvailableCapacityForOpportunisticUsage 424.040 GB.
The difference between the lower two is 12.34 GB, just under 3% of free capacity, although at that time the reported purgeable space was only 1.7 GB. More importantly, the previous measure volumeAvailableCapacity lies between the two new measures. No explanation appears available.
In 10.13.3, the values given for capacity available in the Storage tab, the Finder’s Get Info dialog, and in Disk Utility for the volume are those for volumeAvailableCapacityForImportantUsage, the largest of the three measures. These now appear consistent, although they may not be appropriate in all use cases.
However, they are not consistent with the values given by Disk Utility for the container of the volume: there, the free capacity appears to be based on volumeAvailableCapacity, which is smaller than that given for the volume within the container! That would be fitting a quart into a pint pot, something that even APFS would struggle to achieve.
Indeed, information provided for containers is confusing at best. In my example, the startup volume was shown by Disk Utility as having a single accessible volume. Its container declared three volumes: VM (1.07 GB), the visible Macintosh HD, and a volume ‘not mounted’ (presumably the Recovery volume) of 690.4 MB.
However, two volumes were mounted in /Volumes: the visible Macintosh HD, and another named with a UUID, containing a single property list at /var/db/AdminUserRecoveryInfo.plist That appears to be a mounted disk image from the startup volume, as VolSizes reports identical capacities for it, as for the startup volume.
The evidence in this single case is that High Sierra is more consistent than Sierra in reporting volume capacities, but that disparities exist when comparing containers and volumes. The main problem is that the three different measures are not explained anywhere (as far as I can see), and the reasons for using volumeAvailableCapacityForImportantUsage almost everywhere are not clear.
If you notice discrepancies when using High Sierra 10.13.3, please download and use VolSizes: it should give you a better reference. Please report any such discrepancies here. They would now appear to reflect internal problems in the file system rather than bugs in the tools which report the values. Prior to 10.13.3, I do think that there have been bugs in the tools which may account for previous problems.