The SSD Revolution —

How SSDs conquered mobile devices and modern OSes


TRIM isn't just for toenails

One of the most important operating system features to arrive along with flash drives is support for TRIM. Though it's commonly written in all capitals, TRIM isn't an acronym; rather, it's the name of the ATA command that the operating system can send to the SSD controller to indicate that a certain page or set of pages contains stale data.

The SSD's controller has no notion of files; the only things it understands are pages and blocks. When a file is modified by the operating system, the SSD knows to copy the relevant pages plus the changes being made into new fresh pages, and to mark the old pages as stale; this is possible because the operating system's changes are communicated to the disk drive using logical block addressing, or LBA. The operating system tells the SSD that it is modifying a certain logical block, and the SSD controller maintains a mapping (called the FTL, or Flash Translation Layer) between logical blocks and physical blocks. When the operating system changes a file, it tells the controller to change one or more logical blocks. The controller makes the changes and writes out the appropriate number of new pages, updating the FTL so that the LBAs continue to point at the correct physical locations, and marking the old pages as "stale" pages. Then, at a future time dictated by the controller, the stale pages are left behind by a garbage collection operation and block erased.

Deletions, however, are different. Without TRIM, when the operating system deletes a file on a solid state disk, there's no way for the operating system to tell the SSD controller that the pages can be marked stale. The standardized command set that the operating system uses to communicate down the bus to the SSD has no method to say, "Hey, please mark these pages stale because I deleted the files in them." So, pages containing deleted files continue to be gathered and relocated by garbage collection along with good pages; this increases write amplification and consumes free pages.

TRIM changes this by giving the operating system that missing method to exclude pages containing deleted files from garbage collection. When you delete a file on Windows 7 or OS X (with TRIM enabled on the right kinds of disks) or your favorite GNU/Linux distro (with the right file system, a recent enough kernel, and the right arguments in your fstab file), the pages containing the deleted data are marked stale. The next time the SSD's controller sweeps through to gather up the good pages and move them on, the deleted pages are left behind to be eaten by the block erasure Langoliers. In my head, this looks extremely scary.


TRIM is a relatively recent invention; it's supported by most current SSDs and most current operating systems, but not all. Windows 7 automatically uses it; so does OS X 10.6.8 and later, but only with Apple-provided SSDs. GNU/Linux also supports TRIM, provided you're using ext4 and a kernel newer than 2.6.33.

It's worth taking a moment and examining TRIM support in OS X on non-Apple SSDs. Out of the box, TRIM is disabled in OS X for third-party SSDs, and enabling it requires an app which does some kext hacking and yields mixed results, with some folks saying that it provides a performance increase, others saying that it makes performance tank, and others saying they notice no difference at all. Other World Computing, which among other things resells a line of highly rated SSDs designed primarily for use in Macs, goes so far as to say that its drives are so amazing that they don't need TRIM at all, and that enabling it can actually make the drive less reliable. Unfortunately, the company's blog post on the subject contains no technical information about exactly why this is so, only saying that the SandForce controllers used in OWC SSDs take care of everything and that you should pay no attention to the man behind the curtain. While it's true that LSI/Sandforce does have efficient garbage collection, there is no small amount of hand-waving on OWC's part about the limitations of garbage collection over time—one blog post featured on OWC's site talking about how its Mercury Extreme SSD performs in a MacBook Pro nonsensically states that with the OWC disk installed, "System Profiler does not show TRIM support, this is not an issue, as the OWC SSDs have TRIM support built-in."

I don't doubt that its disks are fast, but OWC deserves to be taken to task for providing marketing-talk in place of actually useful technical information about whether or not TRIM support is necessary. Most damning is the fact that other SSDs based on the same SF-2281 controller as the Mercury Extreme featured in the blog post demonstrably do benefit from TRIM when used on Windows and GNU/Linux.

Bottom line: using an Apple-provided SSD is safest on OS X, since you get TRIM support. Using a non-Apple SSD is fine, too, especially one with good garbage collection (and "good" doesn't necessarily mean "aggressive" since aggressive garbage collection can exacerbate write amplification), but enabling TRIM with a third-party kext hack might cause your computer to eat all of your data. Buyer beware.

Encryption: keeping Eve out in the solid state age

Current operating systems offer whole disk encryption as a security feature, and it's one that is being used more and more often both at home and in the enterprise. Employers tend to mandate encryption because it provides some measure of control over otherwise-uncontrolled data, and because it puts something more secure than an operating system account password between a lost laptop and the potentially malicious person who finds it. Home users like it because it's nominally easy to turn on (though I have in the past spent an incredibly frustrating evening trying to enable Windows 7's BitLocker and make it work with my laptop's TPM chip) and gives them some free piece of mind about whether or not people can steal their identity along with their hardware.

For the most part, whole disk encryption isn't something that greatly affects SSDs, because most SSD controllers don't particularly care what kinds of things they're reading or writing. However, LSI's SandForce controllers once again force us to take a bit of a technical detour because, unlike other SSDs, SandForce-powered SSDs actively do things to the data they write.

Specifically, SandForce SSD controllers perform compression and deduplication on incoming data in an effort to get the write amplification on a given chunk of data below 1. Just because the operating system passes a few megabytes worth of pages down the bus to the SSD to be written doesn't necessarily mean that a SandForce-powered SSD will commit the entirety of that data to flash. Rather, the controller chops the incoming data up into small pieces and compresses those pieces, then looks at the pieces and compares them against the data already stored in flash. If the pieces are identical to other pieces already on the drive, then the controller tosses them out and doesn't bother writing them (more correctly, the controller writes out a pointer to the unique data instead of duplicating it). This lets Sandforce-powered SSDs work more efficiently than other SSDs which aren't doing compression and deduplication.

Deduplication works by not writing anything to flash more than once, but derives its efficiency from having lots of duplicate data to toss out.

Encryption, however, breaks compression and deduplication. Both compression and deduplication work best in situations where there is a lot of repeated information in a given chunk of data, since repeated information can be tossed out and reconstituted later. Modern encryption schemes by their very nature work to eliminate recognizable or repeated patterns in data, since those patterns can be used to puzzle out the thing that has been encrypted.

It's worth noting that SandForce-powered SSDs in fact do encrypt the data on their NAND flash chips, but that encryption is done by the controller and is transparent to the operating system. Pulling a NAND flash chip off of a Sandforce-powered SSD and plugging the chip into a reader will yield only encrypted data; the encryption protects against physical disassembly, but as long as the controller is used to read the chips, the encryption and decryption is handled automatically and the controller's compression and deduplication aren't affected. Even though the data is all encrypted, the controller holds the keys and knows what the unencrypted data looks like.

It's also possible to set up a boot-time password that you must use in order to provide the key to the controller; the presence or absence of the password doesn't affect whether or not the drive is internally encrypted, but rather prevents the disk's controller from accessing its own encryption keys unless you enter the correct password (which itself is used to hash the encryption keys—without a password, the keys are stored unencrypted).

Operating system-enforced whole disk encryption is something else entirely. Because the disk controller isn't involved in the encryption or decryption operations, the only things it sees are endless blocks of data with few or no repeating patterns. Even the proverbial giant PowerPoint file saved in ten different locations—something that if unencrypted would only be written once to flash by a SandForce-powered SSD—stymies the controller. Each of the ten copies of the file, though identical unencrypted, appear to the SSD as ten different chunks of random data. The SandForce controller must reduce its read and write speeds in order to handle reading and writing data without being able to use its bag of speed-enhancing, write amplification-reducing tricks.

Identical files before encryption, and after—deduplication is no longer possible because the files contain no common information.

Fortunately, SSDs are quick enough that the performance impact of running whole-disk encryption on an SSD isn't tremendous; in fact, the delta between the two is often less than running a traditional spinning disk unencrypted versus encrypted. The security benefits of whole disk encryption do seem to more than outweigh the small performance penalties. For Windows 7 and later, this means enabling BitLocker and ignoring it; TRIM continues to work with BitLocker and the operating system will continue to pass down to the SSD information about deleted files. For current versions of OS X, whole disk encryption is provided by FileVault 2, which you can safely enable without problems both on an Apple-provided SSD with TRIM support and also on third-party SSDs. Benchmarks on Anandtech show that the real-world impact of enabling FileVault 2 even on a SandForce-powered SSD is relatively small.

Linux distros, as usual, have more options. Popular distros like Ubuntu include support out of the box for whole disk encryption; third-party applications like TrueCrypt also can be used by those who want more control and more configurability. The same caveats apply, though: there will be some performance penalty, especially with SandForce-powered drives, but that penalty will likely be small.

You must to comment.