I'm trying to learn how full disk encryption using Filevault 2 will impact SSD garbage collection. My understanding is that garbage collection involves moving pages in blocks with free space to empty locations on the drive. However, if Filevault 2 encrypts the entire drive, will the SSD recognize free space as free? And if not, won't that dramatically increase write amplification and decrease the life of the SSD?

I've found a lot of posts on FileVault 2 and TRIM (consensus is it works) and FileVault 2 and SSD performance (consensus is so long as your SSD doesn't have a Sandforce controller - which uses compression - the performance impact is minor), but I'm having less luck learning about how FileVault 2 and garbage collection.


First off, SSD garbage collection and Trim are very different animals. Garbage collection is based on moving existing data, deleting stale data and creating empty blocks in which to write new data. The drive's understanding of the data is nothing more or less than data is there or it isn't. There is no concept of a file system in an SSD's controller. All writes are done at the block level rather than the page level and a block must be erased before it can be written. A drive's garbage collector knows nothing whatsoever about FileVault.

In basic garbage collection without Trim, when the OS deletes the file, it doesn't actually say anything to the controller about the data being stale and available for deletion. The OS merely tracks the address space. The drive will understand that the data is stale in that address if/as/when the OS gives the drive a write command for that address.

So, where Trim comes in is that when a file is deleted at the OS level, the controller on the drive is immediately given the information that the data at that particular address is stale. That enables the drive to handle its housekeeping as soon as convenient upon deletion. And that reduces write amplification.

The improvement of Trim on SSD performance is true even with SandForce. See:


The diagram clearly indicates that there is increased free space for garbage collection with Trim enabled even when using DuraWrite technology.

That out of the way, on to the meat of your question about FileVault 2: Because garbage collection occurs in the SSD without any knowledge of file systems, there is no difference to the SSD whether FV has been enabled or not. To the SSD, there is either valid data, stale data or no data at a particular address.

While whole-disk encryption gives the impression that the data is locked inside a suitcase. That isn't the case. FV2 is scrambling the bits being stored in the pages and blocks. The file allocation and structure of the file system itself remains the same whether FV2 is used or not. And this helps explain why a user can continue to use their system even when a disk is being encrypted or decrypted.

So, in summary, Trim is an enhancement to garbage collection and should be enabled regardless of the controller in use. FileVault 2 will not cause problems for SSDs and users can expect normal write amplification, performance degradation, etc. over time for FV2-encrypted SSDs versus non-encrypted SSDs of the same make on the same system with equivalent use. FV2 volumes will benefit from the use of Trim just as much as non-FV2 volumes.

My system: Early-2008 MacBook4,1; OS X Lion 10.7.5; Crucial M500 960GB SSD; FV2 encrypted; Trim enabled

Useful links for further reading:


Does FileVault 2 interfere with TRIM when using an SSD?


https://superuser.com/questions/315803/how-do-i-resize-a-filevault-2-encrypted-partition (not necessarily 100% related, but still interesting and relevant)

  • Thank you for your response. I do understand that garbage collection happens without knowledge of the filesystem or whether FileVault is functional. But I still don't understand how garbage collection can function as effectively if, as you put it, FileVault "scrambles all the bits". Won't the SSD recognize that free, but encrypted, space as being full, not free? And if so, won't write amplification be a big problem, even with TRIM in place?
    – mesch
    Sep 21 '14 at 22:10
  • Free space is free space. Only the data pages are encrypted. It's not correct to think of whole-disk encryption as being every block on the drive being written to as if it were some kind of encrypted ZIP archive. If you take a drive with 300 GB of free space and encrypted it with FV2, the controller still sees 300 GB of free space after it's encrypted. The DRIVE is not encrypted, all of its DATA is. Sep 22 '14 at 0:17
  • So are you saying that FileVault 2 doesn't fill empty pages on the SSD with scrambled bits? That's contrary to my (perhaps faulty) understanding, and would explain how garbage collection can still work. I had thought FileVault writes to every single page on the SSD, empty or not, during the encryption process (hence the "full-disk" encryption). Isn't that why there is some concern over the use of TRIM with software full-disk encryption like Truecrypt and Filevault 2, because it creates empty "un-scrambled" blocks on the SSD so people can tell what parts of the SSD are used to store data?
    – mesch
    Sep 22 '14 at 11:55
  • "So are you saying that FileVault 2 doesn't fill empty pages on the SSD with scrambled bits? " Correct. Encryption only takes place on the data itself, not the entire volume. Whole-disk encryption for FV2 only means that the operating system is encrypted, not merely the user folder, as was the case with legacy FileVault. This FV2-style of whole disk encryption is also the same as that used with Bitlocker and other encryption strategies. Anything else would be the kiss of death for garbage collection. And, again, there IS NO concern regarding Trim and SSDs (encrypted or otherwise). Sep 23 '14 at 6:52
  • OK I agree that if FileVault 2 isn't filling up free space then garbage collection shouldn't be a problem. This is contrary to every tutorial/document I can find on the subject of how FileVault 2 works though. The description is always "encrypts the entire drive", not "encrypts the entire used drive". Do you have a link to an article/technical document that demonstrates this?
    – mesch
    Sep 23 '14 at 21:52

You must log in to answer this question.

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