How much free space does an APFS disk need?

This has become one of the most popular questions put to me since the arrival of APFS, whether in specifying internal storage for a new Mac, or when managing external disks. The simple answer is that it depends, and here I try to explain some of the more significant things it depends on. To keep this as simple as possible, I consider only disks which will be formatted in APFS, and are primarily used with Big Sur or Monterey.

Are you going to boot macOS from it?

Since Catalina, macOS boot disks have had a formal structure which greatly affects free space. This is also different for the internal SSDs of M1 series Macs, which contain two additional hidden partitions/containers, which aren’t present in Intel Macs or external storage. Thankfully, those additional containers are small, well under 10 GB in total, so don’t need to be taken into account here.

There are now six volumes grouped together in the container from which your Mac boots macOS. As they’re volumes within the same container, they share the same free space. Thus, to work out how much free space that container (and the whole disk) needs, you need to consider how much could be required for each of those volumes, and add them together to give a total.

Preboot and Recovery are both relatively small, and should total well under 5 GB even during updating. The more recent Update volume is very small between updates, but is used for preparation and staging of macOS updates, when it could reach 15 GB or more. The System volume itself is just over 15 GB, and may require a bit more than that during updating. Together these volumes could require a maximum of around 40 GB at their peak.

The size of the VM volume depends entirely on how much virtual memory is required during use. If your Mac has ample physical memory, then it should remain less than 50 KB, but could grow to 20 GB or more if the software running needs much more memory than is available.

The volume that you’re most in control of, Data, stores a mixture of different data, which are reflected in the three different estimates of free disk space:

Free space is the difference between the total storage available on the disk, and that currently in use, and might come to 214 GB on a well-used 1 TB internal SSD.
Space available for important usage is likely to be significantly more, as it represents how much space could be made free when it’s essential. This should allow for the deletion of temporary files, volatile caches, and most snapshots other than the signed and sealed snapshot on the System volume, from which your Mac is booted. This space might be 268 GB.
Space available for opportunistic usage is the lowest of the three, and represents that readily available without removing anything. This might be as little as 203 GB.

The figure shown in the Finder should now be equal to the first of those, and the same as that shown in Disk Utility. Various utilities show the other two, for example my free Mints.

To estimate how much space your Data volume requires from the boot container, you’ll need to know how much is needed for regular files. To that, you should add an allowance for each of the following:

snapshots, if using a backup utility such as Time Machine, which routinely makes volume snapshots of all those volumes it’s backing up;
app temporary and cache files. These vary very widely, and no single figure can be given. You need to know the demands of your apps and your work using them;
macOS working files, such as those in the ~/Library/Trial folder. On occasion these can rise above 5 GB, but that should be very unusual;
system temporary and cache files, which should come to no more than 5 GB or so.

Your Mac’s likely free space requirement for the boot container thus comes to around (40 + 10 + VM + snapshots + caches) GB, plus ‘real’ free space.

Snapshots

Because snapshots will normally be deleted when free space is getting dangerously low, you don’t necessarily have to include them in your allowance. However, if your backup software makes them, it seems futile if they are then to be deleted quickly because the disk is running out of free space.

snapshots

Working on the basis of a 24-hour retention policy, as fixed in Time Machine, to estimate the amount of space required to retain those snapshots, you need to know the file data turnover for each volume within the container during 24-hour periods. Remember that, even if you exclude almost every folder on a volume from Time Machine backup, if it backs up anything on that volume then a whole-volume snapshot will be made every hour.

This poses particular problems with very large apps and their installers, such as Xcode. In normal naïve use, you might copy Xcode’s compressed .xip archive to a folder on your Data or an external volume, decompress it, and move that app into an Applications folder. A snapshot made at the wrong time during that process could require more than 64 GB of disk space until it’s aged out of that volume’s snapshots.

If you don’t want to make allowance for such large snapshots, the simple alternative is to create another volume to be added to the backup exclusion list, so that no snapshots are made of it. Download the .xip archive onto that volume, decompress it there, and finally replace the old version with the new. That will still result in one snapshot containing the old version, but the archive and any intermediate copy won’t take up space in a snapshot.

Putting it together

Assuming that snapshots will never exceed 5 GB in any 24-hour period, and VM and cache requirements are no larger, the total free space required now comes to around 60 GB for the Data volume in a boot container, or less than 10 GB in a normal storage container. Now you can add your own allowance to ensure that you’ve got headroom to use that disk, taking it perhaps to 100 GB for a boot disk, and 25 GB or more for others. If you’re really tight for space, when using a Mac with very little internal storage, or you’re squeezing multiple systems onto an external disk, you can get away with much less, but will be at risk of not being able to update macOS or install a new version of Xcode.

There are other benefits from sizing SSDs and hard disks considerably larger so as to maintain ample free space. One key factor which determines the working life of an SSD is the number of times its storage gets erased and re-written. Thus, a high write load on a small SSD will reach the maximum number of writes more quickly than the same write load on a larger SSD. For a hard disk, keeping the inner sectors free of data will result in faster read and write performance, while filling the disk will lead to slower access to its contents stored towards the centre of its platter.

So it depends…

15Comments

Add yours

1

EcleX on May 18, 2022 at 8:11 am

Many thanks for the useful article. Twice for the “Putting it together” section. BTW, applications like GrandPerspective can be used to find huge files, that could be moved to other disk to free disk space.

LikeLiked by 1 person
- 2
  
  hoakley on May 18, 2022 at 9:28 am
  
  Thank you.
  Howard.
  
  LikeLike
3

zygoat on May 18, 2022 at 4:27 pm

Another thing to consider is that in recent versions of MacOS (11.x and 12.x), the system will silently begin killing running apps without warning when disk space becomes low, presumably due to its inability to allocate as much swap as it would like. (This is a serious UX regression, and one which Apple has so far refused to acknowledge or diagnose; q.v. FB9781495.)

LikeLiked by 1 person
- 4
  
  hoakley on May 18, 2022 at 6:26 pm
  
  Thank you.
  If only someone had asked. This is now expected behaviour, as RunningBoard has come to the Mac from iOS, where it does the same thing.
  So it isn’t a regression, it’s a new feature which has been steadily developing over the last couple of years. Try search this blog for “RunningBoard” and you can all about it.
  Howard.
  
  LikeLike
  - 5
    
    zygoat on May 18, 2022 at 6:33 pm
    
    I struggle to see how the change in behaviour is not a regression (unless you’re being facetious with “it’s not a bug it’s a feature”). In prior versions of MacOS, the system would present an alert advising that disk was dangerously low and that immediate attention was required. I’ve never seen such an alert in a few years; apps are just killed.
    
    Incidentally, I only drew the connection between my apps being killed and low disk condition by accident a few weeks ago. Apple has (of course) ignored my Feedback Reporter report, and I don’t recall reading anything about this in any OS release notes.
    
    LikeLiked by 1 person
    - 6
      
      hoakley on May 18, 2022 at 6:50 pm
      
      A regression is going backwards. RunningBoard is progressing, even if it’s something you don’t like.
      You’ll find my articles about it illuminating.
      Howard
      
      LikeLike
7

Ric Ford on May 18, 2022 at 5:35 pm

Howard, thanks for working through all this to provide a guide. I don’t know if you’ve mentioned this before, but I just discovered that Disk Utility can show snapshots and let you delete them to get more room (View menu > Show APFS snapshots; right-click snapshot for pop-up menu with Delete, Mount, Open in Finder, etc.) Carbon Copy Cloner also has helpful snapshot tools.

For what it’s worth, one experience we had indicated that running with way too little free space can actually damage an SSD and make the Mac unusable until it’s replaced. (In the old days, running out of disk space could also suddently make the Mac completely unusable until it was booted from a different drive.)

Thanks, Ric

LikeLiked by 1 person
- 8
  
  hoakley on May 18, 2022 at 6:28 pm
  
  Thank you, Ric.
  Yes, this feature was introduced in Monterey. If you use the search tool at the top right to search this blog, I have several articles about it, and how to interpret the figures it gives.
  It’s how I got that screenshot above.
  I still like the tool in CCC, but Disk Utility’s is fine, and a valuable addition at long last.
  Howard.
  
  LikeLike
9

Ralf on May 18, 2022 at 9:35 pm

I use Time Machine in combination with Carbon Copy Cloner. I backup with CCC once a day and for a long term backup. Time Machine has the advantage of being able to scroll through recent changes in the Finder if something has gone wrong. Two conclusions: 1. Time Machine only needs to backup one day’s changes. 2. it only needs to back up the folders I would browse through.
This leads to my question: what all can or should be excluded from the backup? Cache, temporary files, applications, local copies of clouds (if they save last changes), system library. If my systems breaks I can reinstall the system.
I think what has to saved is only personal data, user library. What else? What do you think?

LikeLiked by 1 person
- 10
  
  hoakley on May 18, 2022 at 10:08 pm
  
  This depends on which version of macOS you’re running. In Big Sur and later, it can’t back up anything from the System volume, which has to be re-installed using Apple’s installer if needed for recovery.
  Many other parts of the system, like caches, the tmp directory, and so on, are also not backed up by Time Machine. If you’re primarily using TM for short-term backups, then its snapshots are one of its best features, and covers the whole contents of the Data volume, as snapshots are always of whole volumes.
  My TM backups are limited to just a couple of my most active working folders, so are quick to make and take little space. Provided there’s a thorough CCC backup each day, you shouldn’t go far wrong.
  Howard.
  
  LikeLike
  - 11
    
    Ralf on May 18, 2022 at 10:20 pm
    
    Thanks especially for pointing out that TM does not back up the cache etc. So in fact the working folder is will do. Thank you!
    
    LikeLiked by 1 person
12

markbot2zero on May 18, 2022 at 9:45 pm

Thank you, Howard.

By “ample physical memory,” I’m guessing you mean something like ‘enough memory so that Virtual Memory isn’t needed,’ or not needed very often.

Is that about right?

Yesterday, I installed my first Apple Silicon iMac 24″. I had recommended that the client upgrade to 16GB RAM and 512 GB SSD. She got the SSD, but according to the Apple Store employee, the lead time for a 16GB model was 7 weeks (!) so she got the 8GB minimum.

I think she’ll be fine with that. She’s a “typical” user who does mail, browsing, Microsoft Office, Zoom, etc., and not too many open at once, so not too much VM (I hope) and at least it would be spread over 512 GB, not just 256 GB.

And it sounds to me like a good rule of thumb for minimum free space a the boot drive is 100 GB?

Is that also about right?

Thanks again,

-Mark

P.S. re: “In normal naïve use…” This pretty much encapsulates my interactions with Macs.

LikeLiked by 1 person
- 13
  
  hoakley on May 18, 2022 at 10:12 pm
  
  Personally, I prefer to keep a minimum of 200 GB free on my Data volume, but 100 should be fine for anyone not throwing copies of Xcode around. I keep a watch on VM use, and with 32 GB my iMac Pro very rarely uses any at all. She might find 8 GB is a little short, but at least got a decent SSD to ensure any used is small and high-speed.
  Howard.
  
  LikeLike
14

Bruce Michel on May 19, 2022 at 1:14 pm

Your noting of write cycles as a limitation on SSD longevity made me note the copious redundant system log entries for such as AMPDevice…. I believe in another article you called it “diarrhoea”. Perhaps in the totality a small amount of wear but Apple could apply some digital Loperamide.

LikeLiked by 1 person
- 15
  
  hoakley on May 19, 2022 at 4:25 pm
  
  Thankfully, the unified log is a very small contributor to total wear, although it’s more than questionable how much all its entries are really needed in production systems.
  Howard.
  
  LikeLike