4

I've seen recommendations for the minimum amount of free space one should have on an SSD that range from 20%—33%. For instance, this answer (Can MacBook Pro get slower after SSD is almost full?) cites a 2012 Anandtech study (https://www.anandtech.com/show/6489/playing-with-op) that concluded: "Whatever drive you end up buying, plan on using only about 75% of its capacity if you want a good balance between performance consistency and capacity."

The Anantech study was, however, pre-APFS. I understand that APFS is optimized to work with SSDs, so my question is whether that optimization changes (reduces) the minimum free space needed to obtain, using Anandtech's words, "a good balance between performance consistency and capacity."

Further, it's also possible that APFS's different design might mean that the minimum free space needed to obtain a "good balance" should be expressed in absolute, rather than relative (percentage) terms.

I currently have a late-2014 MBP with a 1 TB 4-lane PCIe SSD, with 200 GB free out of 940 GB available on my main partition (I have a 2nd partition with 60 GB available).

I understand APFS can reduce the total storage space needed to store a given set of files (see https://appleinsider.com/articles/17/06/08/inside-macos-1013-high-sierra-apfs-benefits-end-users-with-space-speed), but that's a different attribute from the one I'm asking about. Please also note that I know I can move little-used files to other disks (obviously), but that's not my question. I'm purely interested in learning if APFS affects the minimum free space needed for "a good balance between performance consistency and capacity" and, if so, why it does this.

1

If we assume that the Anandtech study's conclusions are correct, then no, there's no change in the needed free space when using APFS instead of HFS+. You would need no more and no less free space.

It is important to note that the "free space" that Anandtech talks about is not the free space inside the file file system (i.e. part of the filesystem structure that is not currently used for storing user data), but rather free space outside the file system (i.e. part of the disk that has never been written to).

As both HFS+ and APFS support the TRIM command, the essential here happens outside the file system, and thus the change from HFS+ to APFS does not affect the result.

However, you might still observe a performance difference when using APFS compared to HFS+. This is not caused by the free space issue itself, but rather that APFS and HFS+ simply have different performance characterics. Some things APFS does faster than HFS+, and vice versa.

  • I understand from your answer that TRIM is agnostic with respect to the container in which the files are stored. But what about sparse files, which are configured differently by APFS vs HFS+? And more importantly (since I may not have any sparse files), are you certain there are no 2nd-order effects? E.g. (and here I speculate, just to illustrate what I mean by a 2nd-order effect), suppose an APFS-based system needs to run TRIM more or less often than an HFS+ system. In that case, even though TRIM is happening outside the container, the nature of the container could still have an effect. – theorist May 10 at 4:45
  • Yes, TRIM/UNMAP/DEALLOCATE doesn't care which type of file system you use. It operates simply on addresses (i.e. blocks). – jksoegaard May 10 at 8:15
  • Sparse files do not really affect the scenario here directly. It is correct that HFS+ does not support sparse files, and APFS do. The only difference that does in this scenario is that given the same set of files, you'll often have slightly more free diskspace inside the file system when using APFS (because the sparse files have holes that do not use disk space). However, free diskspace inside the file system is not that important here. – jksoegaard May 10 at 8:16
  • Why would APFS need to run TRIM more often than a HFS+ system? - And why would the rate of TRIMs have anything to say? I'm not sure what you mean by TRIM happening outside the container. I assume you mean the file system when you say container - and TRIM definitely only happens within the file system. – jksoegaard May 10 at 8:17
  • Thanks for your replies. In response to your last comment: (1) Rate of TRIMs: Never said it would be different, or have an effect. I was explicit in saying I only gave it as a hypothetical example to illustrate what I meant by a 2nd order effect. But let me instead put it this way: Is there no way in which the nature of the file system could affect write amplification (e.g., might the efficiency of garbage collection algorithms be affected by the file system)? (2) Yes, by container I meant file system. – theorist May 10 at 19:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .