Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OS X El Capitan Opens Door to TRIM Support on Third-Party SSDs for Improved Performance
- Thread starter MacRumors
- Start date
- Sort by reaction score
@triptolemus: You're welcome. Enjoy the stable, new TRIM support! I've converted all of my Yosemite machines to this new method and it feels great knowing that there will be no more gray boot screens or other junk that used to happen with the classic patching method. ;-)
If anyone's wondering what we're talking about, see these two posts:
- Release: Post #220
- Confirmation that it's real: Post #225
If anyone's wondering what we're talking about, see these two posts:
- Release: Post #220
- Confirmation that it's real: Post #225
For the record, we are, and always were agreed on that. I didn't go into details with what I said, but all of what you said was what I tried simplifying. But we can agree that for the majority of people, keeping the system at the "select boot drive" menu overnight, is not at all necessary, right?
Oh, and I see it as very unlikely Apple would keep a list of tested SSDs for consumers. For a few reasons.
1) They don't want people to tinker with their drives. At the very least not on newer machines. This command is for the people who they can't stop tinkering anyway, but they won't support those people massively. Never have.
2) it's work with no benefit.
3) 95% of SSDs work flawlessly anyway
Yes it would be nice, no they won't do it.
Yes and no. It's implemented, but it isn't active. Or that seems to be the case anyway. I haven't confirmed myself, but as you can see in this thread, others have.
Why you're seeing a performance boost, is because you did a wipe of everything. Fairly sure that when you erase all blocks and reinstall the OS, it also allows the SSD to see the free blocks as free
Success - Mac mini late 2012, Yosemite 10.10.3, Crucial MX100 512GB SSD, with TRIM Support = Yes.
found this article today discussing TRIM with linux and 3rd party SSD drives... I'm going to wait on enabling TRIM when El Cap is officially released running on my 840 EVO until l hear from the those in macrumors who are willing to test first.
When Solid State Drives are not that solid
Last edited:
Here's an article that will explain why Apple has been so reluctant to allow TRIM on arbitrary SSDs.
Suffice it to say that, while *most* SSDs that claim to support the TRIM command actually do, *some* have managed to really screw the pooch.
Edit: It's the exact same link donlab posted... I guess that's what I get for not reading 10 pages worth of posts to make sure nobody else had seen that article.
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:
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.
![D1uZQiu.jpg]()
Temptin said:
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.
Last edited:
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. ;-)
Last edited:
Thanks for the explanation. All much clearer now. I do wish Mac upgraders would not tell lies!
The thing that worries me about implementing TRIM if I decide to install an SSD in my Mac Mini, is that I will forget to disable it before doing a PRAM reset. I know you can recover from this by doing multiple commands via Terminal in Recovery mode but having had problems during the Yosemite update where it corrupted my encryption key and the hoops I had to go through to sort that, this is the sort of problem I can do without. I might wait until El Capitan, as that seems to eliminate a lot of the problems potential pitfalls, assuming the TRIM implementation is not deleted in the final version.
The alternative is to put a 1TB hybrid drive in place of the 500GB HDD, as my Mac Mini is only used as a media server and not a daily working machine.
Happy to help! As for your worry about using TRIM Enabler/patching, I agree with you; it's a hassle to face a gray boot screen error if your NVRAM is ever cleared, and it's a hassle to lose the TRIM setting every time you perform an OS update.
But I just edited my post above, to point you to an earlier post of mine which solves all of that: I've brought Trimforce to Yosemite, which means stable, resilient TRIM without any patching, without any risk of boot problems, and it stays enabled even after OS updates.
See the top of Post #232 for the edit.
Wow...went to your website and followed your instructions (took a risk) and used the "Even Better Method (No kext-dev-mode required!)" method and installed the tool in the systems folder and "BAM" it works!!!
Trim is stating that it is enabled. I uninstalled Trim Enabler through the program and hopefully it reset the Kernel. I did that before using your method. It seems to be working....!
I wonder "if" Apple takes this method out of future Yosemite updates or even out of El Capitan, if I keep this and do the same thing when El Cap comes out (if it is not added), will this also still work?
I have the same configuration: Mac mini with the Crucial MX100 512GB SSD. This is why I tried...
Thanks!!!!!
Is the AppleDataSetManagement.kext from OS X El Capitan the same as the one that was used by user Temptin that he produced the fix for OS X Yosemite?
If so, we should save it just in case it does not make it in the final version of OS X Capitan.
Dates and sizes of files in kext are identical, shasum I have not checked. (sorry for my English)
Last edited:
Of course it is! He said so himself. The only thing trimforce does in El Capitan is place that new kext in System/Library/Extensions. Once he verified that, the only thing Tempting did (much to his credit) was to check whether copying that kext over to Yosemite would work as well. He verified that it will work with 10.10.3 and above (not with 10.10[.0], 10.10.1 or 10.10.2).
There's no reason to think that Apple will cripple this. If they had the intention of crippling it, they wouldn't have included the trimforce command to begin with.
Success here too, awesome. Tested this on my cMP 4,1 > 5,1 with 3 SSDs inside (two connected to a Velocity Solo SATA 3 card, and another on an OWC Mount Pro at SATA 2).
Boot volume used was one of them with 10.10.3 Yosemite. My steps:
- deactivated TRIM Enabler 3.3 via the slider button, then clicked on 're-enable kext signing' also
- reboot
- checked in System Report that TRIM Support says NO for all SSDs
- checked in Terminal with 'nvram boot-args' that kext-dev-mode=1 is off
- used the „even better”-method – downloaded the AppleDataSetManagement.kext and installed it
- reboot
and TRIM finally „just works”. @Temptin – thanks, great find.
Last edited:
Simplicity itself. If copying a kext, rebuilding the kext cache and rebooting makes trim possible, erasing that same kext, rebuilding the cache and rebooting turns trim (for third-party SSDs) impossible.
