How Ventura space management tracks changes

macOS space management needs to periodically update its information about purgeable and available space on APFS volumes. Last week’s demonstration was an ideal opportunity to see this system in action.

To recap briefly what I did, I first created a small APFS container (partition) with two volumes inside it. In one, I created two files that almost filled all the free space. I then got Time Machine to make snapshots, and deleted the original files, leaving all that data in one of the volume snapshots. As snapshots are purgeable, I then tried copying a large file to each of the two volumes in turn, to trigger purging of the snapshots and any other purgeable space.

In this sequel I’ll focus on the period between the creation of Time Machine snapshots using the command tmutil localsnapshot and the reporting of the conversion of 94 GB of files to purgeable space, a large and critical change in the availability of space to macOS, apps and the user.

21:21:39 Snapshot creation

The two test volumes created and saved their snapshots at 21:21:39, as recorded by APFS in the log:
21:21:39.455596 apfs fs_insert_snapshot_metadata:246: disk9s1 snap_name='' snap_xid 99 extentref oid 358819 sblock oid 358729
21:21:39.488589 apfs fs_insert_snapshot_metadata:246: disk9s2 snap_name='' snap_xid 100 extentref oid 358719 sblock oid 358692

where TestVolume1 is disk9s1, and TestVolume2 disk9s2. That was confirmed one second later by Time Machine:
21:21:40.598182 backupd TimeMachine Created Time Machine local snapshot with name '' on disk '/Volumes/TestVolume1'
21:21:40.891137 backupd TimeMachine Created Time Machine local snapshot with name '' on disk '/System/Volumes/Data'

The timestamps incorporated into the snapshot names also confirm these were made at 21:21:39.

That’s life for a file system: APFS does all the work, and TimeMachine takes all the credit!

21:23:05 File deletion

The next significant file event was dragging the two files totalling 94 GB from TestVolume1 to the Trash, and emptying it to delete them, leaving 94 GB of purgeable space on that volume. This was recorded in the log as:
21:23:05.951514 Finder AppKit trackMouse send action on mouseUp
21:23:05.952317 Finder Trash being emptied = yes

21:23:06 Disk space update

The deleted service then called for an update to disk space figures. This was completed first for TestVolume2, which had no changes made:
21:23:06.232391 deleted totalAvailable ENTRY, Volume: /Volumes/TestVolume2, Calling process: deleted
21:23:06.232393 deleted totalAvailable info CACHE_DELETE_QUERY_PATH : REFRESH
21:23:06.232396 deleted totalAvailable info CACHE_DELETE_NO_CACHE : 1
21:23:06.232397 deleted totalAvailable info CACHE_DELETE_EVENT_KEY : CACHE_DELETE_EMPTY_TRASH
21:23:06.232398 deleted totalAvailable info CACHE_DELETE_VOLUME : /Volumes/TestVolume2
21:23:06.232399 deleted totalAvailable info CACHE_DELETE_ID :
21:23:06.232401 deleted caller has requested a forceRefresh (CACHE_DELETE_NO_CACHE = YES)

That was completed within 0.3 second of the Trash being emptied. In a further 6.6 seconds, the Finder was provided with an update to the purgeable space now available on TestVolume1:
21:23:12.880829 deleted Successful Request
21:23:12.880846 deleted took 0.039548 seconds for Calling process: Finder, on volume: /Volumes/TestVolume1, returned: 94000054272
21:23:12.880847 deleted CACHE_DELETE_AMOUNT : 94000054272
21:23:12.880848 deleted CACHE_DELETE_VOLUME : /Volumes/TestVolume1
21:23:12.880853 deleted servicePurgeable returned

That was reported in full just over 2 seconds later:
21:23:15.008925 deleted <<<PurgeableOperation Result (Finder, query path: SLOW, u: 3, ET: 2.205167):
21:23:15.009002 deleted CACHE_DELETE_TOTAL_AVAILABLE : 94000054272 (94.00 GB)
21:23:15.009067 deleted CACHE_DELETE_TOTAL_FSPURGEABLE : 0 (0 Bytes)
21:23:15.009072 deleted CACHE_DELETE_CALLING_PROCESS : Finder
21:23:15.009088 deleted CACHE_DELETE_VOLUME : /Volumes/TestVolume1
21:23:15.009103 deleted CACHE_DELETE_ELAPSED_TIME : 2.120686958333333 (2 Bytes)

Thus, the Finder must have been informed of the availability of 94 GB of available space in TestVolume1 9 seconds after the files had been deleted from it.

Then the figures were returned for the unchanged volume:
21:23:15.044381 CacheDelete CACHE_DELETE_TOTAL_AVAILABLE : 159744 (159.74 KB)
21:23:15.044255 CacheDelete CACHE_DELETE_TOTAL_FSPURGEABLE : 0 (0 Bytes)
21:23:15.044271 CacheDelete CACHE_DELETE_VOLUME : /Volumes/TestVolume2
21:23:15.044414 CacheDelete Query Result>>> 159744 bytes on: "/Volumes/TestVolume2".

21:23:55 Disk Utility

Those changes were already reflected in the figures displayed in Disk Utility, as captured in two screenshots at 21:23:55 and 21:24:09.


TestVolume1 now has a Capacity of 100 GB, 100 GB Available, 94 GB Used, and 94 GB Purgeable.


TestVolume2 now has a Capacity of 100 GB, 6 GB Available, with only 160 KB Purgeable, while Other Volumes have 94 GB Used.

21:30:09 Finder

At 21:25:38, trying to copy a 10 GB test file to TestVolume2 was refused by the Finder:


At 21:26:46, 3 minutes and 31 seconds after the Finder had been informed of the changes, this was the state of the two volumes shown in Storage:


But when I took this screenshot of two Get Info dialogs for the volumes in the Finder at 21:30:09, almost 7 minutes after deleting the files and 6 minutes after being informed of the changes, updates to space weren’t shown correctly:


Note that modification dates shown for the two volumes are given as 21:22 for TestVolume1 and 21:25 for TestVolume2. That might imply that the figures given for TestVolume2 had been updated after the creation of 94 GB of purgeable space for TestVolume1, immediately following the trashing of files.

Successful purge of TestVolume1 was initiated at 21:32:55.068.


Recalculating and reporting the change in space on the two volumes took around 9.1 seconds, and was reflected in Disk Utility within 50 seconds. However, Storage remained misleading over 3 minutes after the change in space, and the Finder was completely incorrect over 7 minutes after the files were trashed and converted into purgeable space.

Changes to the contents of APFS volumes such as the deletion of files can thus initiate an update to space management figures. Although recalculating purgeable space then takes time, it should be reported within seconds rather than minutes. Disk Utility was also seen to request updates to purgeable disk space, although those weren’t as thorough and were completed more quickly.


In this demonstration using an external SSD, changes in purgeable space thus in available space should have been relatively quick and simple to recalculate. They are likely to be made more complex and slower to report when:

  • there are many files in the changed volume;
  • there are multiple volumes in the container;
  • there are many snapshots involved;
  • many apps have run recently, so require purgeable files being checked in their caches;
  • storage is on a hard disk rather than SSD, and has fragmented file system metadata.

There are reports that in some cases updating purgeable space can take many seconds or even minutes, but it’s hard to imagine how in this demonstration the period could exceed 7 minutes, particularly when Disk Utility had updated correctly within 40 seconds. However, there’s evidence in the log that Disk Utility obtains its own estimates of space from CacheDelete to display, a process I’ll examine in more detail in a future article.