Am I understanding correctly that I can TRIM my boot drive if I boot into recovery and repair with Disk Utility? This is without Trim Enabler on, correct? If so, this is not working for me. There is no message in DU saying that it TRIMed the disk. Am I misunderstanding?
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.
TRIM Support no longer 'easy' in Yosemite
- Thread starter Sharky II
- Start date
- Sort by reaction score
No, trim is not loaded in recovery mode and thus not active, although this is the way to run "Repair" on the boot drive ... just no trim. You may be able to trim with the Terminal commands from recovery, however I have not tried that. If you search these forums you will find the recommended Terminal commands for trim.
You will have to have another bootable instance of OS X which supports trim, enable it there, and then repair your boot disk from that other copy.
I'm late to the game...
I'm going to replace my Mac Mini 2012's HD with Samsung 840 EVO SSD this weekend. I only read about the TRIM issues with Yosemite after buying it. I have no problems disabling kext signing, security issues, etc (coming from Windows world...) and occasionally going through the temporary re-enable hoops to update the OS.
My question concerns the "occasional" automatic, non-user initiated PRAM reset. Is this something that occurs often or seldom? Are there specific events that cause PRAM resets? I don't reboot my MM very often, so I don't think it will be an issue.
I'm going to replace my Mac Mini 2012's HD with Samsung 840 EVO SSD this weekend. I only read about the TRIM issues with Yosemite after buying it. I have no problems disabling kext signing, security issues, etc (coming from Windows world...) and occasionally going through the temporary re-enable hoops to update the OS.
My question concerns the "occasional" automatic, non-user initiated PRAM reset. Is this something that occurs often or seldom? Are there specific events that cause PRAM resets? I don't reboot my MM very often, so I don't think it will be an issue.
The PRAM should not automatically clear itself.
Even though it happen, you may still able to boot with TRIM Enabled (assuming you use TRIM Enabler). Cindori really did his best to make the system as stable as possible. Reset PRAM may cause Yosemite unable boot to desktop, but not necessary happen. It's already proved by few of us.
I even perform my 10.10.1 upgrade without disable TRIM. No problem at all. Of course, TRIM will be disabled automatically after update, and I have to enable it again.
To TRIM or not to TRIM, that is the question.
I've given up on TRIM, and do this instead:
dd if=/dev/zero of=trim.tmp bs=1024 count=10241024
rm trim.tmp
Which writes zeros to all empty parts of the file system, until the disk fills up.
A similar technique is used by recent Linux distributions to avoid the performance penalties and buggy software risks of TRIM on delete.
And this method will effectively trim everything, not just newly deleted sectors.
The main downside is the disruption of having the disk fill up to complete the operation. This would not be a good idea for server class machines.
I've given up on TRIM, and do this instead:
dd if=/dev/zero of=trim.tmp bs=1024 count=10241024
rm trim.tmp
Which writes zeros to all empty parts of the file system, until the disk fills up.
A similar technique is used by recent Linux distributions to avoid the performance penalties and buggy software risks of TRIM on delete.
And this method will effectively trim everything, not just newly deleted sectors.
The main downside is the disruption of having the disk fill up to complete the operation. This would not be a good idea for server class machines.
Last edited:
Perhaps I misunderstand what you're doing, but zeroing and Trimmng are two different things. From what I know, zeroing won't help at all and could actually be the worst thing to do, as filling all your drive with data (zeros or otherwise) forces it into a degraded performance state. Trim actually tells the SSD which data it no longer needs to keep (such as when a file is deleted). How does what you're doing accomplish that?
AFAIK, TRIM will tell the SSD which block of data is not being used anymore. So, GC can be more effective (no need to move any useless data before it zero out the whole cell). Therefore, less write cycle to the SSD, and speed up the write process.
Without GC to zero out the "free" cell when the SSD is idle, TRIM will be effectively useless.
I don't really know the mechanism behind. However, if GC can works better with TRIM (an OS level function) because GC is a SSD internal background function, and doesn't know which cell's data is useless. But if this command is a OS level command, which able to tell the SSD which cell can be zero out. Then this is basically running GC + TRIM manually in the foreground. It sounds like will speed up the subsequence write process until the SSD is full of useless data again.
I personally still prefer to use TRIM. In fact, use TRIM Enabler is simple and painless so far. And I don't know if there is any potential risk (e.g. data corruption) to run this command. Also, I has no idea how to monitor my SSD and run this command at the correct timing (Too early, waste of time. Too late, reduce performance). So, the automatic background functions like TRIM + GC still my 1st choice.
Without GC to zero out the "free" cell when the SSD is idle, TRIM will be effectively useless.
I don't really know the mechanism behind. However, if GC can works better with TRIM (an OS level function) because GC is a SSD internal background function, and doesn't know which cell's data is useless. But if this command is a OS level command, which able to tell the SSD which cell can be zero out. Then this is basically running GC + TRIM manually in the foreground. It sounds like will speed up the subsequence write process until the SSD is full of useless data again.
I personally still prefer to use TRIM. In fact, use TRIM Enabler is simple and painless so far. And I don't know if there is any potential risk (e.g. data corruption) to run this command. Also, I has no idea how to monitor my SSD and run this command at the correct timing (Too early, waste of time. Too late, reduce performance). So, the automatic background functions like TRIM + GC still my 1st choice.
They are closely related.
When an SSD is forced to "garbage collect", if it has data it can't know is junk, that forces a lot of I/O operations. However piles of zeroed sectors are very readily garbage collected by reasonably smart firmware. In addition a zero'ed sector can be immediately written to, even if it's not in a free map.
Note that SSD's have four possible ways to implement TRIM itself, including leaving the old data in place, or zeroing the sectors (Reference 7.10.3.2 Trim in the ATA/ATAPI command specification).
OS's similary have choices of not supporting TRIM (that would be Yosemite for 3rd party SSD's), supporting TRIM on delete (Windows), or batch trim (many recent Linux versions).
Unfortunately not every SSD firmware reacts the same to TRIM or zeroing sectors. The zero trick does work for me. Running the above command is quite fast the second time, indcating the firmware notices the sectors are already zero and it skips actually writing them. Those curious to explore TRIM (on Windows systems) can check out "TrimCheck" https://github.com/CyberShadow/trimcheck . Unfortunately SSD vendors don't explain how their drives work very well, but you can read one vendor's writeup about zeros here: http://www.xtremio.com/saved-by-zero . Also note the underlying flash memory can only turn 1 to 0 so some people recommend writing 0xff rather than zero.
Last edited:
So is periodically running this risky or does it have any downside in order to carry out a "batch" TRIM of an SSD?
You sure? Some weeks ago I turned on my macbook and I saw only "stop sign", so I musted to make clean install of yosemite. Don't want to get it again..
You sure? Some weeks ago I turned on my macbook and I saw only "stop sign", so I musted to make clean install of yosemite. Don't want to get it again..
If you need to do system updates for OS X, make sure to turn Trim Enabler off first. Otherwise, you risk getting the stop sign at boot.
I use to think that as well, but I inadvertently updated to 10.10.2 the other day without thinking to disable trim enabler on my Mini and it updated just fine. So has something changed, was that false advice, or was I just lucky?
Nothing changed, it's just an extra precaution up to this moment. Not really necessary in the last few updates. However, due to no one knows what will happen in the future updates, it's a recommended procedure to avoid troubles.
This is what happened to me, then once I got it started and the new OS loaded, it put trim in a incompatible software folder. So I put it back in the active apps folder and tried to update to 3.3 and it says "Update Error, the update is improperly signed".
I had no choice but to update to 10.10.1 since one of my new camera's raw file thumbs would not be readable without doing it, a productivity standoff.
So I still have the old trim, it is not enabled and I have a ton of work to do and don't want to hose it....now what?
Yeah it went fine for me too when I upgraded to the beta. I would be careful though. That beta is trouble. I have been testing it on my rMBP and it has been problematic. I would still be running it on my Mac Pro but it did something one time it rebooted (still don't know what) and since I had TRIM enabled it brought me to the prohibited sign at boot. I used the Terminal app in the Recovery Partition to fix it and when I booted back into the OS I couldn't get TRIM to work again. Finally what I ended up doing was erasing the drive, reinstalling OS X, and manually dragging my data back from my Time Machine volume (no Migration Assistant used here).