Temptin

macrumors member
Jun 16, 2015
52
86
@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
 

casperes1996

macrumors 603
Jan 26, 2014
6,388
4,293
Horsens, Denmark
It would help if Apple shared the work they already had done. if there is a prototype lab that qualifies some SSDs for use in Apple systems and they test some as "OK" and others as very clear failures then listing that is helpful. They don't have to test all possible drives on the market, but for what they are going to do away if is more information for the folks who may want to buy a 2nd or 3rd or alternative drive.

Drive X with firmware A.B.C. is OK
Drive Y with firmware A.E.F has known interaction problems with OS X.

Throw another disclaimer on that list that it is limited in scope ( not exhaustive test of market and never will be. )

They do it with 3rd party 4K monitors ( at least list the ones that pass )

https://support.apple.com/en-us/HT202856

These monitors work with OS X 10.x.y. That is a useful starting place for customers to look for options. That is waaaaaaay better than leaving the users in a fog.

Secondly it would lend some credibility to their disclaimer that there is a possibility of data failure/corruption. "We had tested and got some failures" is confirmation. "We only pass stuff that we sell" is without much substantive proof.




File system allocation/deallocation isn't the only source of Garbage. The SSD controller moves data around also ( wear leveling , block consolidation , etc. ). The notion that the garbage collector is completely lacking in information unless handed to it by an explicit TRIM call is far more dubious than the than Crucial suggestion.




It is not Mac user idle time, it is disk time. OS X runs many processes than just the. The "stop the OS from running" is remove the condition you end with there from being part of the equation no matter what the user workload is or isn't. Stop the OS from running, put there far more simpler bootloader into pause mode and pretty much can guarantee there is disk idle time. Background Time Machine running? No. Twitter/social media caching notifications on the disk? No. myriad of background processes doing storage updates? No.

If the idle time being allowed isn't really all that idle then this is a first step work around.

TRIM doesn't change the data ( some data de-duplication of zeroed blocks may make it look like it, but that isn't mandated by the standard. ). It only feeds metadata to the SSD ( and its garbage collector). When something is actually done with the info is later. If don't give drive a idle time to do housekeeping it won't get done.

Crucial's recommendation is that "put disks to sleep" is turned off. For normal users and usage that is probably enough. But if usage is abnormal then the boot idle trick pretty much will remove any OS X impediment to allowing the drive time to do some housekeeping.




If the OS says "go to sleep" then it very likely won't. Garbage collection means moving ( writing) data. SSDs can't do writing in a low power state. Writing is actually the highest power mode of a SSD.

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.

So happy to hear this. I just did an ATA-Secure Erase a few days ago on my Samsung 840 and did a fresh install of Yosemite and happy and surprised to see that my read/write speeds are at 500 MB/s Did they implement the TRIM support in the current version? Or am I missingn someting. I was never able to achieve those speeds before when I had Yosemite.

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
 

triptolemus

macrumors 6502a
Apr 17, 2011
602
777
@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

Success - Mac mini late 2012, Yosemite 10.10.3, Crucial MX100 512GB SSD, with TRIM Support = Yes.

Crucial Yosemite TRIM Enabled.png
 
  • Like
Reactions: loby and Temptin

donlab

macrumors 6502
Jun 3, 2004
300
88
USA
Personally I think Apple should just show "TRIM enabled" in System Profiler and in IOKit even if TRIM commands are never sent. That would make everyone happy.

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:

tbrinkma

macrumors 68000
Apr 24, 2006
1,651
93
This is very good news! Not sure why it has taken Apple this long to do this - I guess their philosophy of "use the machine only as it came from us" is waning at least on older machines where user replaceable hard drives are present.

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. :oops:
 

Temptin

macrumors member
Jun 16, 2015
52
86
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:

Temptin said:
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.

D1uZQiu.jpg
 
Last edited:

wilsonlaidlaw

macrumors 6502
Oct 29, 2008
432
63
I am told that most modern SSD's have their own garbage collection systems and TRIM is not required .....or is this sales BS?
 
  • Like
Reactions: satcomer

Temptin

macrumors member
Jun 16, 2015
52
86
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. ;-)
 
Last edited:

wilsonlaidlaw

macrumors 6502
Oct 29, 2008
432
63
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. ;-)

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.
 

Temptin

macrumors member
Jun 16, 2015
52
86
Thanks for the explanation. All much clearer now.

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.
 
  • Like
Reactions: loby

Eweie

macrumors regular
Oct 5, 2013
144
80
only plebs don't know how to enable this. I'm sure hackintosh users know better.
 

chambone

macrumors 6502a
Dec 24, 2011
969
25
Netherlands
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/Yosemite_Patchless_TRIM.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!)
Hey, thanks for sharing this! Works on two laptops here.
 

loby

macrumors 65816
Jul 1, 2010
1,233
811
Success - Mac mini late 2012, Yosemite 10.10.3, Crucial MX100 512GB SSD, with TRIM Support = Yes.

View attachment 561913

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!!!!!
 

amors

macrumors member
Jul 14, 2013
68
13
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!
I took AppleDataSetManagement.kext from El Capitan (System/Library/Filesystems) and installed it in Yosemite (/System/Library/Extensions).
TRIM works.
 

loby

macrumors 65816
Jul 1, 2010
1,233
811
I took AppleDataSetManagement.kext from El Capitan (System/Library/Filesystems) and installed it in Yosemite (/System/Library/Extensions).
TRIM works.

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.
 

amors

macrumors member
Jul 14, 2013
68
13
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?
Dates and sizes of files in kext are identical, shasum I have not checked. (sorry for my English)
 
Last edited:

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,215
201
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?

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.
 

Fangio

macrumors 6502
Jan 25, 2011
370
467
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 [...]
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:
  • Like
Reactions: Temptin

bikejack

macrumors newbie
Nov 20, 2009
25
0
Temptin thanks so much for your terrific work and info. I used the "even better method" and trim is enabled on my ADATA SX 900 SSD and working great. Just curious is there anyway to turn trim off now.
 

PeterHolbrook

macrumors 65816
Sep 23, 2009
1,215
201
Temptin thanks so much for your terrific work and info. I used the "even better method" and trim is enabled on my ADATA SX 900 SSD and working great. Just curious is there anyway to turn trim off now.
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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.