Most of us prefer a simple life. If we want to know how much money we have in a bank account, we expect a clear statement of the balance now. If we want to know how much free space is left in a volume, then we expect the file system to know and to give us that figure. With APFS, it just isn’t that simple.

Traditional file systems (HFS+)

To work out how much free space is left on a traditional file system like HFS+, all we need to do is total up the storage blocks occupied by data that hasn’t be deleted, take that total away from the total capacity of that volume, and convert the answer to bytes.

There are few factors to complicate this: some files are stored compressed, but so long as macOS doesn’t need to decompress them to disk, they don’t change in size. There are plenty of temporary files and caches, whose size can change substantially, but so long as the calculation refers to a particular instant in time, we can live with that.

Snapshots

The most obvious confounding factors with many APFS volumes are snapshots. The snapshot itself consists of a copy of the file system metadata, which is of limited size, and small relative to the size of the disk. What takes up space dynamically are the deleted storage blocks required to revert to that snapshot. Their total size increases steadily the more we use that volume after making the snapshot, and it’s not uncommon for the data held by a snapshot to increases to many GB, as I have explained in detail here.

Book-keeping for snapshots gets more complex when there are several, and some are deleted. This makes it impossible to give a single figure for the total size of any given snapshot, as the space freed up by deleting it also depends on whether other snapshots are deleted at the same time.

If you’ve deleted snapshots, you’ll also be aware that freed space may not be returned immediately. These slight delays are the result of APFS using a different mechanism (Reaper, rather than Space Manager) for freeing space occupied by larger file system objects.

Clones

When files are duplicated or copied within the same APFS volume, macOS tries to perform this by cloning. This is similar to making a hard link, in that the new file is created in the file system, but no data are actually copied to create the duplicate. So long as the two files don’t change, no additional storage is required for the pair, but as the data for the two files diverges, changed storage blocks are written to disk until eventually they are two completely separate files.

Accounting for clones in terms of space used and free is difficult. Although the Finder reports clones as taking up disk space as if they were separate files, its overall figures for space used and free should tally with those reported by Disk Utility, and only account for storage blocks used.

To put these into numbers, let’s say my disk has 500 GB free and I clone a 100 GB file or folder in the volume on that disk. While the size of the cloned file/folder is reported as 100 GB, there should still be 500 GB free. Apps that total up the declared size of files and folders can therefore overestimate the space they use, compared with that reported by APFS for that volume.

Sparse files

Sparse files are specially created, and contain little data compared to their overall size. For instance, a database might build itself a data file that’s full of empty data, maybe 5 GB in total, of which only 4 KB is used. If it uses the right calls to macOS to do this, a sparse file is created to contain only the 4 KB, with no space wasted saving empty data. In the early days of APFS, these were uncommon, but have since become increasingly frequent.

The problem with sparse files is that, while appearing relatively small, any operation which doesn’t preserve their special sparse format causes them to explode to full size. One that’s guaranteed to do this is copying the sparse file to a file system like HFS+ that doesn’t support the format: that 4 KB then expands to its full 5 GB without any warning. Similarly, saving a sparse file using an app that doesn’t make the right calls to preserve its format will convert it to full size.

Other volumes

In the past, when we’ve been working with HFS+ volumes, they don’t share free space with anything else. Create a 500 GB HFS+ volume and unless you repartition that disk, it can only ever hold a maximum of 500 GB. APFS containers now take the role of HFS+ volumes/partitions, and all the volumes within that container share free space.

Most of the other volumes in your Mac’s boot volume group have relatively fixed size. The two most likely to change size significantly are the Data and VM volumes, which share free space. While you have control over what’s in the Data volume, macOS determines how much of the VM volume it uses, if any. If your Mac does use swap space, that’s taken from the free space available to your Data volume.

You don’t control free space

With a traditional file system, you largely control how much free space is available in a volume with a fixed size. With a modern file system like APFS, it’s the file system and macOS that control free space.

Although my Data volume is currently said to have 823.41 GB used and 164.81 GB free, that will change substantially following the deletion of snapshots, and depending on what happens to clones, sparse files, and how much swap space is required by the VM volume. That figure for free space is for what macOS terms “important usage”, such as updating macOS. The system can also give an estimate of free space available for “opportunistic usage”, which is significantly lower at 152.46 GB, for general use including documents and media libraries.

That same Data volume had 9.8 GB of snapshots stored. When those were deleted, free space rose to 196.55 GB, and that for “opportunistic” usage to 182.82 GB. By deleting less than 10 GB of snapshots, I’ve profited an additional 20 GB of free space.

Such is the arithmetic of APFS.