The greatest number of comments about the early beta-releases of Big Sur have centred on its redesigned interface, rather than internal issues. But one which comes up frequently is the storage space which it consumes. Even for a beta, Big Sur has a voracious appetite for disks: as one leading developer, Jeff Johnson of @lapcatsoftware, discovered, when updating from the first to the second beta, macOS swelled to 27 GB in size. This is the result of its use of snapshots.

Not only does Big Sur use a snapshot of the current system for its Signed System Volume, but it makes and keeps one of your previous installation too. When your startup disk has half a terabyte free, that may escape notice, but for us lesser mortals, and anyone trying to manage Big Sur in less than 100 GB, it really gets in your way. I’m sure that those figures will improve by the time that Big Sur is ready for release, but that isn’t the point: once the system has made that snapshot of the previous installation, there seems no easy way to discover how much disk space the snapshot is occupying, and the only way to free up that space seems to be performing a clean install of macOS.

Even in Catalina, it’s all too easy for disks to lose substantial amounts of free space to snapshots which are no longer required. In theory, this should never happen, as Apple has been rigorously controlling which apps can create snapshots, to ensure that they don’t become orphaned or forgotten. Another theory says that, unless a user installs one of the few third-party apps such as Carbon Copy Cloner, the only contact they should have with snapshots is in Time Machine.

Unless you enter the sprawling realms of the command tool tmutil, though, that gives no insight into, or control over, its snapshots. Even tmutil doesn’t reveal anything about snapshots made by the system, for which you’ll need a command such as
diskutil apfs listSnapshots /Volumes/volname
which lists snapshots for the mounted volume named volname. Obtaining information about their effective size requires another command, perhaps du, but results for that don’t appear encouraging.

This is a problem peculiar to snapshots. Although the snapshot itself is tiny, the data which it accumulates over time only grows in size. This is because it also retains old blocks which have been replaced with new data, since the snapshot was made. On a normal data volume, it may only grow at a rate of a few GB per day. With a major system update, blocks retained by the snapshot can be similar in size to the whole update, as seems to happen when updating from Big Sur beta 1 to beta 2.

The obvious place for tools to work with snapshots is Disk Utility, which steadfastly denies all knowledge of them, other than giving an estimate of ‘purgeable’ disk space which could perhaps be reclaimed if you could identify and delete unwanted snapshots. If you really want to know what’s going on with your snapshots and why free storage space is disappearing, the best tool at present is Carbon Copy Cloner.

The best tool at present is Carbon Copy Cloner – a great compliment to Mike Bombich and his team, but what a reflection on Apple and one of the leading features of its new and proprietary file system APFS.

Yet again, Apple has introduced a powerful new technology, put it to good uses in macOS, and forgotten to provide users with the tools to support them. Or maybe it’s pretending that snapshots are problem-free, and that we’ve all got limitless storage. Or just that users can’t be trusted to maintain their own Macs.

By all accounts, Big Sur extends the use of snapshots substantially. They’re an essential part of its new Signed System Volume, appear to be key enablers in its ability to make Time Machine backups to APFS volumes, and feature in its system installations and updates. Yet the tools we’re provided with for the management of snapshots are almost completely absent. Even the diskutil command given above will reveal the UUID of every snapshot, and its XID (whatever that is), but not its effective size.

We need Disk Utility to be able to list all snapshots stored on a volume, and their current effective size, together with a command to delete those which are purgeable. Is this really too much to hope for three years after Apple introduced APFS and snapshots?