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.

theorist
  • 805

1 Answers1

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.

jksoegaard
  • 77,783
  • 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 '19 at 04: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 '19 at 08: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 '19 at 08: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 '19 at 08: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 '19 at 19:45
  • (3) TRIM happening inside vs. outside file system: In your answer, you wrote: "As both HFS+ and APFS support the TRIM command, the essential here happens outside the file system." It seems there's a typo there, so it's hard to understand, but I took your language to mean that TRIM happens outside the file system. However, in your comment, you wrote "TRIM definitely only happens in the file system". Could you please clarify the former statement? – theorist May 10 '19 at 19:48
  • @theorist There's no typo that I can see? ... What I meant was that IF for example HFS+ supported TRIM and APFS didn't - THEN there would be a difference. As both support TRIM, there's no difference regarding what happens inside the file system. I.e. what really has an effect here happens outside the filesystem (i.e. in the amount of space you never allocate and thus never use). – jksoegaard May 10 '19 at 20:36
  • And yes, ofcourse there's ways in which a file system could affect write amplification - however your question was not about write amplification, you asked about free space. Keep in mind that we're comparing two "reasonable file systems", if you were to build an "unreasonable" file system that stored every file three times on the device or something like that - ofcourse that's going to affect write amplification. Or if you had a file system that deliberately fragmented every file. Etc. Similarly HFS+ and APFS really do not have many "good" factors regarding write amplifications. – jksoegaard May 10 '19 at 20:42
  • Yes, APFS implements sparse files - but the effect on a standard user's file system is not large. Neither of them implements compression, deduplication or similar that would have a strong effect. However, you could say that APFS is designed to support compression in the future - but it doesn't right now. – jksoegaard May 10 '19 at 20:43
  • (1) This is what I thought was a typo (probably a missing word), because this phrasing didn't make sense to me: "the essential here". Initially I guessed the missing word was "action" (as in "the essential action here"), where I took "action" to mean TRIM. But based on your subsequent explanation, I think what you meant to say was "the essential difference". – theorist May 10 '19 at 23:31
  • (2) You wrote "of course there's ways in which a file system could affect write amplification". But: Couldn't the amount of write amplification in turn affect the needed free space? And if this is the case, wouldn't it then also be the case that file system design could, at least in principle, affect the needed free space, even if both use TRIM? This is the type of 2nd-order effect I've been asking about from the start of these comments. – theorist May 10 '19 at 23:45
  • It’s like asking if a Toyota Aygo or a Citroen C1 needs the most fuel to drive from Paris to Rome - and I say that the difference is so small that it is not worth talking about - and you then say: “But couldn’t a car exist that would need much more fuel?” ... Yes of course such a car could exist, but it is neither the Aygo nor the C1. I hope this analogy makes things clearer for you. – jksoegaard May 11 '19 at 07:51