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='com.apple.TimeMachine.2023-04-15-212139.local' snap_xid 99 extentref oid 358819 sblock oid 358729 21:21:39.488589 apfs fs_insert_snapshot_metadata:246: disk9s2 snap_name='com.apple.TimeMachine.2023-04-15-212139.local' 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 'com.apple.TimeMachine.2023-04-15-212139.local' on disk '/Volumes/TestVolume1' 21:21:40.891137 backupd TimeMachine Created Time Machine local snapshot with name 'com.apple.TimeMachine.2023-04-15-212139.local' 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 : com.apple.cache_delete 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 com.apple.TMCacheDelete: Successful Request 21:23:12.880846 deleted com.apple.TMCacheDelete 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 com.apple.TMCacheDelete 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.

purge05

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

purge06

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:

purge08

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:

purge09

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:

purge07

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.

Timeline

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.

Delays

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.

8Comments

Add yours

1

kapitainsky on April 24, 2023 at 7:09 pm

Fantastic insight into how macOS subsystems account for free space. It shows clearly that concept of free space in modern file system is not exactly what it used to be. In any moment of time it is only an estimate. Transactional and asynchronous nature of FS like APFS makes exact number impossible. It is a challenge for developers. But maybe we just have to realize that something so obvious as how much free space I have on my FS is not anymore right way to think. Old good days are gone:)

LikeLiked by 1 person
- 2
  
  hoakley on April 24, 2023 at 7:10 pm
  
  Thank you.
  Howard
  
  LikeLiked by 1 person
3

kapitainsky on April 24, 2023 at 7:16 pm

BTW for many reasons systems like ZFS – which is more mature than APFS and was even considered at some stage as a file system for mac (https://arstechnica.com/gadgets/2016/06/zfs-the-other-new-apple-file-system-that-almost-was-until-it-wasnt/) recommends critical minimum of “free space” to be 20%. It is what it is – to enjoy all new perks we need some room for FS to do its job.

LikeLiked by 1 person
- 4
  
  hoakley on April 24, 2023 at 8:55 pm
  
  Thank you.
  I used to recommend percentages to be kept free, but on large SSDs that seems unnecessarily generous, and I suspect that APFS is best off with a minimum of 100 GB, at least on a disk containing a Boot Volume Group. I don’t think this is so much APFS, but more the tricks that macOS uses, for instance when updating the SSV. We’ll see as I move deeper into CacheDelete and space management.
  Howard.
  
  LikeLiked by 1 person
  - 5
    
    kapitainsky on April 24, 2023 at 9:04 pm
    
    Sort of agree. % is not ideal metric as it is very different story when working with 128GB drive vs 8 TB one. And HDD vs SSD. There are many factors to consider. TRIM, over provisioning, daily changed data volume etc. For this I do understand Apple – it is consumer system. Very few people want to worry about it (and it is right IMHO). Only what I miss is freedom to make informed decision when more workload heavy usage is needed.
    
    LikeLiked by 1 person
6

jmrichards7f14f5632c on April 25, 2023 at 12:03 am

I have seen other sites that say for an SSD one should not go much beyond 50% utilization, because to do so slows down the performance of the SSD drastically. But I see you have your SSDs well above that shockingly low recommendation. Do you see any performance degradation at higher usage? I can understand why on a rotating drive that would get more fragmented as it filled up, but the SSD does not really care about fragmentation. Another rationale for keeping lots of space open on an SSD seems to center on heat generation and the resulting slowdown, plus a lack of headrrom for the SSD to do “maintenance,” whatver that implies. Do your tests show performance degradation as the drive fills?

LikeLiked by 1 person
- 7
  
  kapitainsky on April 25, 2023 at 6:51 am
  
  In my opinion for casual usage I doubt performance degradation can be noticeable. Said that everything depends on workload. When running app like database overwriting 100s of GB per hour then it can make difference but very few of us use such heavy applications. Now most noticeable impact for me personally would be macOS purging TM snapshots. My computer writes about 100 GB daily and all these changes have to be tracked by snapshots as I run backup only once a day so if I had let’s say 50 GB of free space then I am in trouble – Time Machine will still works but wont be able to safe space by doing differential backups.
  Please note that it does not matter what size of disk is in use – it is rather volume of changes vs free space story.
  And BTW I also keep 50% of my disk free:) It is probably too much but definitely does not do any harm:)
  
  LikeLiked by 1 person
- 8
  
  hoakley on April 25, 2023 at 7:48 am
  
  Thank you.
  I suspect whoever has written those articles neither understands how SSDs work nor has ever used them for real!
  The internal SSD in this iMac Pro has been well above 50% utilisation ever since I first migrated to it over four years ago. I not infrequently run benchmark tests, and they haven’t changed much since it was brand new and the SSD essentially empty.
  It’s a good way to sell expensive SSDs, I suppose. But if they were really so bad at storage, how come they ever caught on?!
  Howard.
  
  LikeLiked by 1 person