For users looking to upgrade their older Macs with third-party solid-state drives (SSDs), one issue has been a lack of support for TRIM on these drives under OS X. TRIM is a system-level command that allows the operating system and the drive to communicate about which areas of the drive are considered unused and thus ready to be erased and rewritten to. In the absence of TRIM, users can see significantly slower drive writes as the drive begins to fill up.
Officially TRIM has only been supported on Apple's drives, and while tools such as TRIM Enabler have been developed to turn on TRIM for third-party drives, they ran into issues under OS X Yosemite due to Apple's use of kext signing. With this security measure in place, users have had to disable kext signing in order to enable TRIM, and should kext signing be turned back on such as by resetting NVRAM/PRAM during troubleshooting, the user's system will refuse to boot.
Since the developer release of OS X El Capitan on Monday, a number of users interested in TRIM support have been investigating the possibilities for TRIM on third-party SSDs, particularly with the new "rootless" security features that prevent access to many system-level files.
Some users have been playing with various options involving turning off rootless temporarily in order to run utilities like TRIM Enabler, and members of our forum have discovered a simple command to enable built-in support for TRIM on third-party drives that can be enabled once rootless has been disabled. The developer behind TRIM Enabler and others have confirmed the method does work and are making plans to enhance their software to support it.
Enabling TRIM using this method does come with a warning from Apple, as it can cause issues on occasion and the company wants to make sure users are operating it at their own risk.
This tool force-enables TRIM for all relevant attached devices, even though they have not been validated for data integrity while using that functionality. By using this tool to enable TRIM, you agree that Apple is not liable for any consequences that may result, including but not limited to data loss or corruption.
Apple could certainly make changes as development on OS X El Capitan continues, but given the built-in trimforce tool it certainly appears the company intends to allow TRIM to run on third-party SSDs. The "man" documentation for the trimforce command indicates it was introduced in OS X 10.10.4, which remains in developer testing, but forum member mikeboss has determined it is not present in the current developer build.
While most users will never need to deal with this issue, upgrading to an SSD is a popular way to squeeze some more speed and life out of an older Mac, so there is a sizable community of users interested in getting TRIM to function on their third-party drives, and some of them may find TRIM a helpful tool.
Top Rated Comments
The following is the original post from before the edit, and has nothing to do with the above edit:
----------------------------------------------------
Geez... there's a lot of combined issues in that article...
The first issue is the queued TRIM implementation in Linux. It is the only operating system that tries to send FPDMA QUEUED TRIM (a new SATA II extension of NCQ, and therefore also called NCQ TRIM). The latest Samsung firmwares mistakenly set word 77 bit 6 to 1 in the ATA IDENTIFY flags, which tells the OS that they support FPDMA QUEUED operations, when they actually don't. If you try to send a FPDMA QUEUED TRIM, the latest Samsung drives spectacularly overwrite random data with zeroes. The Linux kernel now blacklists those drives from trying to use FPDMA QUEUED TRIM, since they're misbehaving with that command. The Samsung engineers are aware of it since the issue first surfaced a year ago, but a fix is not yet ready.
So if you've got a modern Samsung drive, it's important that your OS uses regular sequential TRIM. Linux is the only OS that uses queued. All versions of OS X (even El Capitan) and Windows (latest) still use sequential TRIM, and will continue to do so for the foreseeable future.
Next up... the article is actually about a bug in the Linux kernel's sequential (non-queued) TRIM implementation.
You see... It's not just SSD firmwares that sometimes implement TRIM badly. The OS can do it wrong too, if it sends out incorrect TRIM commands that tell the SSD to delete data that's actually in use. You need the OS filesystem driver to understand the filesystem at a deep level so that it knows exactly how to properly TRIM it, and it also needs to be aware of what data is on the drive and what data is in the memory-buffered filesystem (which may be out of sync with what's on the drive), so that it knows exactly what data it will tell the SSD to delete. It's a very complex science and it even took Windows a while to get it right due to peculiarities in the NTFS filesystem. In the linked article's case, Linux is the culprit. They're talking to Linux kernel devs to get it fixed.
Since OS X and Windows use sequential TRIM, the followup questions become:
* A) Does my drive implement sequential TRIM properly?
* B) Does the OS implement sequential TRIM properly?
For A, the answer is YES for all modern drives. But NO for *old* drives such as early SandForce controllers. *THAT* is why Apple displays the warning saying that you're enabling TRIM at your own peril. It's also the reason why Apple only allowed TRIM on their own drives initially; because back when they first implemented TRIM in OS X 10.6.8 (July of 2011), a lot of popular drives had buggy TRIM implementations - and it's better to have a slow untrimmed drive than a corrupt drive.
For B, we need to find out whether the OS sends out correct TRIM commands and doesn't send out anything that would tell the drive to delete valid data. To test this, I coded a benchmark that first writes a 50 GB verification-file (a very large file, covering a lot of SSD surface area, and whose contents can be verified to be intact later), and it then writes and deletes/TRIMS over 1000 gigabytes of data, and then pauses to let the drive perform its TRIM and garbage collection, to be sure that all the TRIM commands have been carried out. The test was executed several times on a Samsung 850 PRO SSD (same one used in the article you guys linked to), on OS X Yosemite and OS X El Capitan.
Every single bit of the 50 GB test file stayed intact, thus proving:
* A) Yes, the Samsung 850 PRO with latest firmware implements old-school sequential TRIM properly.
* B) Yes, OS X (even El Capitan) uses *sequential* TRIM and has a proper TRIM implementation that *doesn't* tell the drive to delete random valid data.
So as long as your SSD properly implements sequential TRIM (and all modern ones pretty much do, since TRIM is default in Windows and all drives want to support Windows), then you'll have zero issues with enabling TRIM in *any* version of OS X.
And do we need TRIM? Yes. The SATA TRIM command was invented to solve an extremely important need: It's the *only* way for an OS to tell an SSD to free up space from deleted files. Without TRIM, the SSD will think that *all* blocks are in use until the OS tries to overwrite them again. If all blocks are marked as in use, the SSD is literally *physically full*, and in that state it will be extremely difficult for the SSD's garbage collection to try to passively free up a bunch of empty space for new writes to take place. So all further writes will first go into the SSD's on-board buffer (that's fast), but then they'll sit there for a long time as the SSD reads, merges and re-writes data (that's extremely slow). A lack of TRIM also causes write amplification, as the SSD's garbage collection shuffles around all blocks of dead/old data from deleted files that the SSD still thinks are in use and thinks must be preserved. TRIM is the only command that can let an OS tell an SSD that the data from a deleted file is safe to delete during garbage collection. If the drive had been properly TRIM'd, the SSD would have known that most of the space is actually free, and its garbage collection would be allowed to free up those blocks in the background so that they're ready for new writes. Garbage collection is basically a process that does two things: Erase TRIM'd blocks (the primary source of freeing up space on the disk for new writes), and erase overwritten blocks that have been invalidated by new data (that's only responsible for freeing up a *tiny* amount of the storage space on an SSD). So garbage collection without TRIM is like a runner with one leg. It works (kinda), but it's crippled.
Now relax, don't panic, and remember to always carry a towel.
To thank Apple profusely for this move is classic Stockholm syndrome.
#legitness
But either way you won't run into any problems, they both still work.
2. The vast majority of Linux code now comes from corporations/paid developers:
(http://www.linuxfoundation.org/news-media/announcements/2015/02/linux-foundation-releases-linux-development-report)
3. I seem to remember someone else working in their parents garage who did Ok?