OS X El Capitan Opens Door to TRIM Support on Third-Party SSDs for Improved Performance

Edit: This post has a lot of visibility, so I'd also like to point your attention to an earlier post of mine which gives you safe TRIM in Yosemite 10.10.3 and up:

I've investigated how "trimforce" works and written up a method for doing stable, patchless TRIM enabling on OS X 10.10.3 or higher. No more boot issues, and no more loss of the TRIM settings after OS updates. Trimforce + Yosemite = Yes!

https://github.com/Temptin/Documents/blob/master/OSX_TRIM_Tutorial.md

(Be sure to read the whole page so that you understand the legal implications. And consider giving this post a thumbs up to help others discover it!)

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.

Apple has actively sabotaged the long-term performance of non-Apple branded SSDs for years. Now they might finally provide a standard (though somewhat convoluted) way to enable TRIM without hacking the kernel extensions.

To thank Apple profusely for this move is classic Stockholm syndrome.

AWESOME SAUCE!!!!

#legitness

Updates are coming to Trim Enabler and Disk Sensei to take advantage of the Apple sanctioned way of enabling Trim. We're finally going to get Trim on the Mac without compromising system security or stability.

This is the problem with Open Source programming - often it is done by people living in their parents' garage or basement.

1. This is massively insulting to anyone who has ever contributed to Linux

2. The vast majority of Linux code now comes from corporations/paid developers:

* The number of paid developers is on the rise, as companies aggressively recruit top Linux talent. More than 80 percent of kernel development is done by developers who are being paid for their work. Volunteer developers tend not to stay that way for long.

(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?

Is yours an early or late 2011? I have the late 2011 15" MBP and have been wanting to go SSD for a while but have read some about some issues surrounding this particular model. Can you offer me any insight based on your experience?

I'd recommend Crucial over Samsung, got an 840 Evo in my 2012 15" MBP and I really wish I went Crucial. Fitted 50+ Crucial SSDs in Win/Mac systems @work in addition to 7 in friends' MacBooks and they just seem to run much, much smoother.

But either way you won't run into any problems, they both still work.

I am told that most modern SSD's have their own garbage collection systems and TRIM is not required .....or is this sales BS?

It's complete bullsh#t. The rumor was mostly started by the morons at Crucial. The same morons who posted a freaking YouTube video benchmarking a drive with Blackmagic Speed Test with and without TRIM enabled. That shows a *spectacular* lack of understanding of what TRIM does. You can't "benchmark TRIM". The drive needs to be idle (resting) for TRIM to even be carried out, so an actively running benchmark would never allow TRIM to take place! Moreover, the SSD needs to be *full* of data. You can't benchmark it on a fresh drive like those utter morons did. Crucial's marketing department are about as reliable as asking a homeless man about how to win at the stock market.

People sometimes bring up another company by saying that "even SandForce states that TRIM is not necessary", but their CTO has gone on record saying that even their drives need it. And why wouldn't they? If anyone understands what TRIM does, you know why *every* drive on the planet needs it, and why the need for TRIM will *never* go away even with future drives. Without a way to tell a drive that data is no longer in use (that's what TRIM does)... you'll have no way to tell a drive that data is no longer in use. Shocker, eh?

TRIM is an extension to garbage collection, which tells the garbage collector what data is safe to delete. Without TRIM, the garbage collector is operating at something like 20% effectivity.

Read my comment above yours; the end explains what you just asked about in detail. ;-)

Best News I have heard all day!!!!! I hope Apple does not close this option. Thanks Apple. PLEASE don't close out this option!

And THANKS to all who developed the way and the coding!!

Sucks for TRIM Enabler. As someone that saw millions lost due to Apple adding features from software we sold, I know how it can hurt. On the other hand it is great to have functionality built-into the OS.

Enabling Trim has always been a free part of Trim Enabler.

And Trim Enabler was created from the start as an alternative to running a Terminal command. The whole purpose of it is to offer a better user experience, and it will continue to do so in El Capitan, utilizing this new improved functionality.

You obviously have little experience really dealing with various formats. If HFS+ is a problem, you don't have it too bad. But please tell us about your obscure formatting option or one that is far less efficient and why you know better than a huge team of developers.

obscure formatting option?! far less efficient? what in the world are you talking about? I am talking about HFS+ which is the only file system I use. Its deficiencies with regards to data integrity are well-known and I am hardly the first person to point them out. yeh, I am by no means an expert on file systems but I know that some modern ones like ZFS do perform error checking on access. It's high time Apple developed a replacement for HFS+ that would do that too. At the very least that would prevent corrupted data from being silently copied over backups which is what HFS+ does. and I couldn't give less of a damn that some huge group of developers think it's ok for my data to get corrupt overtime with no effective way to stop it.