Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

OS X 10.10.4 Experiences (and trimforce)

crjackson2134 said:
I turned TE off and removed it. I then used the trimforce command to enable everything.
Click to expand...

When updating my MBP mid-2012 (with a Samsing 850 EVO 250gigs), I did not know I had to turn off TRIM Enabler before installing the update. When it restarted my Mac after the update, I checked TRIM Enabler and it was disabled. It's only at that time that I discovered on the web the trimforce Terminal command and activated it. TRIM is now activated when checking my computer properties.

Could the fact I did not turn off TRIM enabler before updating hurt my Mac?

Thanks.
 
Enabled trim on an aftermarket Transcend 500 SSD for my 2010 MBA. I honestly wasn't worried about degraded performance on this machine but good to know it's more optimized now.
 
Cindori said:
There will be updates to Trim Enabler and Disk Sensei tomorrow that will actually make them a more safe way to enable Trim on OS X than trimforce.

I've received Apple's approval on a new driver that will enable Trim on 3rd party drives without writing anything to /System. This allows for Trim enabling without disabling system security (rootless) on El Capitan, as well as the following for OS X Yosemite 10.10.3 or above:
  1. Disabling kext signing is no longer necessary
  2. The “gray boot screen/stop sign” issue is gone
  3. Your system is no longer modified in any way
  4. Trim will no longer reset on updates
Coming tomorrow :)
Click to expand...
Did not see the update yet - still on schedule for release Today?
 
It will not be a GUI switch for trimforce, it will install a custom signed driver that enables Trim.
This has the benefit of not writing anything to /System, and thus not requiring to disable system security on El Cap (like trimforce does).

macpeach55 said:
Did not see the update yet - still on schedule for release Today?
Click to expand...

A few hours away.
 
Glad that Apple finally did this. Thanks to all of the people who sent feedback to Apple to make this happen. But...it feels kinda anti-climactic now. LOL
 
Val-kyrie said:
So are you saying that enabling Trimforce in El Capitan will disable "rootless" system integrity protection whereas Trim Enabler will enable Trim without disabling the "rootless" security protection?
Click to expand...

Correct. At least for the beta.
 
Can we get a list of supported SSD's and unsupported SSD's for this terminal command?
 
Installing this update did not go smoothly. Like many others, I wasn't able to update through the App Store - I was getting the same hangups with 100% CPU usage and massive memory leaks. Decided to update through Terminal rather than downloading the Combo Update from Apple's website. I disabled TRIM and Kext signing prior to starting any updates.

I had no idea that this update included SMC and EFI changes. Upon rebooting, I heard that eerie BIOS-sounding chime on a blank screen. Not the normal OS X chime - the one I'm used to hearing when dealing with Windows boot issues. After the chime, I sat there staring at a black screen for a while with no action. I waited a bit more and finally had to manually power down. After powering back on, the normal looking OS X Update-style gray progress screen appeared, and seemingly booted OK after that. I've been paranoid ever since, though my machine seems to be running just fine.

System info says I'm running 10.10.4. My BootRom is MBP81.0047.B2A and my SMC is 1.69f4. I checked Apple's EFI and SMC updates page, and those numbers seem to look ok for an early 2011 15" MBP.

Has anyone else experienced this? Would I know by now whether something went wrong when the update flashed EFI / SMC by now?
 
I would like to know the security issues with trim and encrypted drives, what type of key they are using (128 or 256) and if secure erase (hardware encryption) can be used in OSX. Haven't been able to find this info.
 
Cindori said:
It will not be a GUI switch for trimforce, it will install a custom signed driver that enables Trim.
This has the benefit of not writing anything to /System, and thus not requiring to disable system security on El Cap (like trimforce does).



A few hours away.
Click to expand...

You disable system security long enough to enable trim force then re enable it again. This isn't a glaring security hole. Its two reboots and your done. At least for the first beta
 
tgd85 said:
...I had no idea that this update included SMC and EFI changes. Upon rebooting, I heard that eerie BIOS-sounding chime on a blank screen. Not the normal OS X chime - the one I'm used to hearing when dealing with Windows boot issues. After the chime, I sat there staring at a black screen for a while with no action. I waited a bit more and finally had to manually power down. After powering back on, the normal looking OS X Update-style gray progress screen appeared, and seemingly booted OK after that. I've been paranoid ever since, though my machine seems to be running just fine.

Has anyone else experienced this?
Click to expand...
Yeah, I had the black screen during a firmware update on my Early-2011 MBP (under Snow Leopard). I think it was the Lion Internet Recovery EFI update for Early-2011 models. I solved the problem with a shutdown/restart.

tgd85 said:
...Would I know by now whether something went wrong when the update flashed EFI / SMC by now?
Click to expand...
I doubt that. The firmware updater checks the validity of the new firmware before it deactivates the old firmware.
 
  • Like
Reactions: tgd85
I assume it's running perfectly
imac 27" mid 2011 - 3,1ghz/16ram/Samsung 850pro 256gb (Revision: EXM01B6Q)

TkCn4s.jpg

o1qCIJ.jpg
 
Last edited:
  • Like
Reactions: Cindori
Mr. Retrofire said:
They do not need trimforce, because OS X (10.6.6 or newer) recognizes them as "Apple SSDs".
Click to expand...

I know that in system profiler I see that TRIM SUPPORT: YES is shown, however, does the drive automatically process TRIM functions or is using a program such as Disk Sensei from @Cindori for the auto trim or manual trim still required and/or beneficial?
 
swingerofbirch said:
Apparently, it takes 100% CPU utilization for the Mac App Store just to check if there are updates. So far it won't show anything for me and I eventually have to force quit the App Store. I was just going to update iTunes as I won't update to 10.10.4 until I've done a more recent complete back-up. This is the point Apple's software quality has come to. Their huge thing was having a new music service that came out yesterday. During that day I was at no point able to update iTunes to use the new music service. Can you imagine how Tidal would have been treated in the press if that were the case with their service? And how can just checking for an update take up so much processor usage? My computer sounds like it's ready for take-off with the fans blasting each time I try opening the App Store. This is why I do complete back-ups before ".1" updates now, which is another sign of Apple's software quality decline. Maybe they need to bring back optical drives and send out discs because they have never gotten the hang of Internet services. In fact they are going backward. Updates worked much better under the Software Update app versus the App Store. Spotify updates itself automatically all the time, and it's working on top of Apple's technologies. Apple controls every part of my eco-system: the Mac, the OS, my wireless router, but it just doesn't work anymore.
Click to expand...


Just fyi if this happens, its possible your library update folder is a little borked up. open terminal and do
cd /library/updates
sudo rm -rf *

then reboot and launch app store.
 
Would @Cindori or anybody else with knowledge of OS X's inner workings with HFS+ and TRIM please clear up the confusion with Samsung 8xx series and some Crucial SSDs?

From what I understand, the implementation of NCQ (queued) TRIM commands is buggy on some of these SSDs and may result in blocks being zeroed when it's occupied by a file, resulting in data corruption.

Some drives apparently never had the problem fixed (Crucial M500), som have had firmware updates that say they fixed the problem, but apparently didn't or did, depending on who you ask (M550).

With Samsung drives, some people are saying the bug isn't related to TRIM at all, which is strange.

Windows apparently doesn't issue queued TRIM commands and Linux has worked around it by blacklisting the affected drives so that only non-queued TRIM commands are issued.

Now, my question is, does this issue affect OS X's handling of TRIM? The Linux pages describing it suggest it affects both Linux and OS X, but some people point out that OS X's implementation of TRIM on HFS+ doesn't use queued TRIM commands either.

Which one of these is true?

If the queued TRIM bug does occur on OS X, the best solution would be for @Cindori to release updated Disk Sensei and TRIM Enabler with custom signed drivers as mentioned previously that do the same sort of queued TRIM blacklisting on affected drives as Linux is doing.

Thanks!

For the record, I have Crucial M500 and MX100 drives on various Macs and I found out about this issue around the same time people noticed the new trimforce command in El Capitan and have since turned off TRIM on all of them until I can be reasonably sure it's safe.
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back