Enable TRIM on Mac OS X for any SSD drive

Here's unofficial way to activate TRIM on Mac OS X for non Apple SSD drives.

I can confirm that this works with Corsair Force F120 with MacBook Pro 13" (2011 early).

http://www.hardmac.com/news/2011/03/25/how-to-activate-trim-on-any-ssd

It's not much tested, so do it on your own risk.

Modifying kext file may bring your OS unbootable so read the instructions carefully. Make backups before modifying the files.

Before rebooting, rebuild extension cache (not needed if using the tool below):

sudo touch /System/Library/Extensions/

Edit:

I recommend to use the Trim support enabler tool.

Trim support enabler does the changes for you, so you don't need to touch the system files manually.

It has also possiblity to revert the changes. Please see following threads:

http://forums.macrumors.com/showthread.php?t=1125400

http://www.hardmac.com/news/2011/03/27/the-universal-solution-to-activate-trim

In any case boot fails, boot to safe mode by holding shift while booting up. Then run the trim support enabler tool to revert the changes

Same here. Quick question: Does a F120 with FW1.0 support TRIM correctly? I will try to update the FW to 2.0 later this week but only if I have to.

RAM GUY: Are there any noticeable advantages between 1.0 and 2.0 on a mac?

Kind regards,

JP

All force drives have TRIM support regardless of the firmware version. (It was only the older SSDs, X and P series that need firmware update to support TRIM.)

If your system is stable with FW1.0 then I would leave it. You only need version 2.0 if you are having any crashes or stability problems. There is no performance difference between the two as confirmed by myself and several other users with benchmarking.

Had to deinstall it. While writing and reading was ok all remove operations took forever. A simple rm on a 500MB file took appr. 10 seconds. After restoring the original driver the same rm took milliseconds. The same applied to tons of rm operations in Mail. Deleting 1400 mails suddenly took minutes.

Now since others have not reported this, may this after all be a problem with the firmware?

Kind regards,

JP

I don't know much about that hack but I'm basing my assumption off your post alone: this hack performs TRIM directly after each delete so that's why it takes longer.

Under normal operation, when you delete a file on an SSD, the file is not actually deleted but rather "flagged for deletion". When the drive/system is idling, TRIM activates and goes to actually reset the blocks. Everything seems quick to the user, and the blocks are mostly truly empty so you can write back to them much faster.

Without TRIM, the block is only ever marked for deletion, and when you go to write over it then it ends up taking forever because the block has data in it (hence your typical performance degradation if you don't use TRIM).

This is my understanding, I could be completely off. :p

Personally I would still use this method even if it takes a while to delete files, you are maintaining the performance of the drive. The tool may be broken in a sense that it TRIMs after every delete rather than waiting until the system is idle so that you don't notice it.

Had to deinstall it. While writing and reading was ok all remove operations took forever. A simple rm on a 500MB file took appr. 10 seconds. After restoring the original driver the same rm took milliseconds. The same applied to tons of rm operations in Mail. Deleting 1400 mails suddenly took minutes.

 

Now since others have not reported this, may this after all be a problem with the firmware?

 

Kind regards,

JP

I created with dd 320 x 1.3MB files and 40 x 13MB files. Moving files to trash with Finder took like 1 second and emptying trash was instant.

So totally 936MB and 360 files.

Still in FW1.0? What computer model and OS X version? How filled is your disk and how long used?

Did you use thrash and was the trashing or emptying trash take time. Or rm from terminal?

Maybe after enabling trim you should do "erase free space" to trim out the free space.

After erasing free space you should do:

sudo chown root:admin /

sudo kextcache -system-prelinked-kernel

sudo kextcache -system-caches

When you reboot first time after erasing free space and running these commands, at least for me, spotlight did reindexing, and that took a while.

Please see also this thread:

http://forums.macrumors.com/showthread.php?p=12288844&highlight=#post12288844

Also check the beginning of above thread about speed tweaks after enabling Trim.

Edit:

made also test in terminal:

-rw-r--r-- 1 bogey staff 977M 1 Huh 10:33 file1000MB

-rw-r--r-- 1 bogey staff 977M 1 Huh 10:33 file1000MB.1

-rw-r--r-- 1 bogey staff 977M 1 Huh 10:33 file1000MB.2

-rw-r--r-- 1 bogey staff 977M 1 Huh 10:34 file1000MB.3

-rw-r--r-- 1 bogey staff 977M 1 Huh 10:34 file1000MB.4

Bogeys-MacBook-Pro:~ bogey$ time rm file1000MB*

real 0m0.094s

user 0m0.001s

sys 0m0.088s

great thread, thanks :)

most definitely seeing improvements, boots within 6 seconds of the apple logo/spinning wheel

I created with dd 320 x 1.3MB files and 40 x 13MB files. Moving files to trash with Finder took like 1 second and emptying trash was instant.

So totally 936MB and 360 files.

 

Still in FW1.0? What computer model and OS X version?

MacBook Pro 15", late 2010. OS X 10.6.7.

Still in FW1.0 since the upgrade is a PITA. I cannot install Windows 7 on the disk due to not having a local DVD anymore (and booting from an external is not working). I suspect hooking it up to a USB adapter will not do the trick since that would be easy. If you suspect changes from 1.0 to 2.0 to be responsible I will invest the hours though.

How filled is your disk and how long used?

120GB disk, 49GB free

In order to have everything trimmed I created files to fill it up completely and then rm those. I expected this to take long. However my findings were afterwards.

Did you use thrash and was the trashing or emptying trash take time. Or rm from terminal?

I tried both. But the times reported were using rm from terminal.

Maybe after enabling trim you should do "erase free space" to trim out the free space.

That's what I by filling up the disk and then erasing the files. I think. :-)

After erasing free space you should do:

 

sudo chown root:admin /

sudo kextcache -system-prelinked-kernel

sudo kextcache -system-caches

Interesting. I can see how this might affect boot times (but resetting PRAM speeded that up incredibly, you should do that every once in a while). But why would that have any impact on further rm operations?

Also check the beginning of above thread about speed tweaks after enabling Trim.

With the exception of the motion sense tweak (since I have a hard disk in the macbook as well) I did all of that. This is without TRIM enabled:

jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile1 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 4.119463 secs (254541902 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile2 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 4.005939 secs (261755358 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile3 count=1000 bs=1024k
41000+0 records in
1000+0 records out
1048576000 bytes transferred in 4.016811 secs (261046892 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile4 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 4.033160 secs (259988696 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile5 count=1000 bs=1024k
ls -l1000+0 records in
1000+0 records out
1048576000 bytes transferred in 4.057391 secs (258436029 bytes/sec)
jkoopmann:tmp jkoopmann$ ls -lh tempf*
-rw-r--r--  1 jkoopmann  staff   1,0G  1 Apr 13:45 tempfile1
-rw-r--r--  1 jkoopmann  staff   1,0G  1 Apr 13:45 tempfile2
-rw-r--r--  1 jkoopmann  staff   1,0G  1 Apr 13:45 tempfile3
-rw-r--r--  1 jkoopmann  staff   1,0G  1 Apr 13:45 tempfile4
-rw-r--r--  1 jkoopmann  staff   1,0G  1 Apr 13:46 tempfile5
jkoopmann:tmp jkoopmann$ time rm tempfile*

real	0m0.064s
user	0m0.001s
sys	0m0.059s
jkoopmann:tmp jkoopmann$ 

I then re-enabled TRIM. Reboot. Reboot time from rEFIt to spinning ball below apple 7seconds and then an additional 19 seconds until Login Prompt, then the same test:

jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile1 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 3.987873 secs (262941167 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile2 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 3.973232 secs (263910084 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile3 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 3.927041 secs (267014270 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile4 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 3.932894 secs (266616899 bytes/sec)
jkoopmann:tmp jkoopmann$ dd if=/dev/zero of=tempfile5 count=1000 bs=1024k
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 3.939644 secs (266160083 bytes/sec)
jkoopmann:tmp jkoopmann$ time rm tempfile*

real	0m8.133s
user	0m0.001s
sys	0m0.207s

As you can see 8.133 seconds vs. 0.062 seconds.

Next try with TRIM still enabled (right after the first one):

jkoopmann:tmp jkoopmann$ time rm tempfile*

real	1m31.009s
user	0m0.001s
sys	0m0.370s

Subsequent tests way over 1m20s. Once TRIM was disabled things are back to normal. This surely cannot be correct.

Regards,

JP

How long have you guys had Macs? You seem to know the OS very well.

With regards to the firmware update, there should be a way to get a bootable USB/external drive with a live CD windows environment..check out Hiren's Boot CD or UBCD4Win. At least one of them should have a package and instructions to get it working on a bootable drive.

I see what you're saying.

Given that your problem here is due to a TRIM hack alone I don't think the firmware 2.0 would help, but if you can eventually get it working then it might be interesting to see if anything changes.

It sounds to me that your two best options are either parallels or bootcamp. Bootcamp is much better and stable overall, but parallels is a little easier to setup.

The TRIM hack is not really a hack. It is not faking TRIM. It is simply enabling the TRIM functionality that is built into the system. So either Apple is doing something wrong in the OS or we have a problem with the firmware.

Bootcamp: How do I install bootcamp without booting Windows from the internal DVD (which I do not have)?

Parallels: Are you saying that the firmware update is supposed to work within a VM? How so? A windows within parallels is not even seeing the SSD hardware.

There are ways to install windows from within windows without a DVD drive using drive emulation, or imaging software like norton ghost or acronis, but I don't know enough about Macs to know how to do it. It's probably possible, but extremely difficult.

Have you tried parallels? I haven't seen any reports of people updating the firmware with parallels but it would be worth a shot. I'm not sure why it wouldn't see the SSD hardware, do you mean in the firmware update tool? Make sure you right click the tool and use Run as administrator (even if your account is administrative).

There are ways to install windows from within windows without a DVD drive using drive emulation, or imaging software like norton ghost or acronis, but I don't know enough about Macs to know how to do it. It's probably possible, but extremely difficult.

In order to install it in bootcamp I need to boot a windows or legacy os (meaning non Mac-OSX) at some time in the process. And if the hardware/BIOS prevents me from doing so I am screwed. I will have to plug in my DVD back at the SATA port and see how it goes from there.

Have you tried parallels? I haven't seen any reports of people updating the firmware with parallels but it would be worth a shot. I'm not sure why it wouldn't see the SSD hardware, do you mean in the firmware update tool? Make sure you right click the tool and use Run as administrator (even if your account is administrative).

Parallels runs a virtualized Windows. Those VMs do not have any access to the hardware directly. The VMs only see virtualized pseudo-hardware. So the harddrive the Windows within Parallels sees is a virtual disk on the F120, not the F120 itself. How would that help?

I haven't done fw upgrade for my drive but this is what I have understood:

1. there is only Windows based firmware installer available for Corsair F series.

2. When using Windows installer, the drive what needs to be upgraded, needs at least one Windows partition

3. You can't boot off external HDD, so you need to install Windows to internal HDD.

4. Parallels does not see the drive

options how to do the upgrade:

1. Make backups of your data.

2. Create small partition with bootcamp for Windows installation

3. Load Windows recovery dvd and start console (or install whole Windows)

4. Do the fw upgrade.

5. After upgrade partition can be removed and mac os partition resized back.

or

1. Make backups of your data.

2. Create windows partition using bootcamp

3. put it to windows pc

4. do the fw upgrade

5. put the disc back to mac and windows partition can be removed

or

1. Make backups of your data.

2. Take the drive out of mac

3. put it to windows pc

4. create image of the drive with some cloning software

5. repartition the drive with windows partition

6. do the fw upgrade

7. clone the image back to disc and install back to mac

Is there a linux fw updater? Then maybe Ubuntu live CD could be used.

Not quite. I cannot install Windows in Bootcaml without an internal DVD. Which I do not have. Windows installation will not work using USB. Hence the problem. For the small Windows partition I do not need imaging. Bootcamp assistant works like a charme. But if I cannot boot the Windows installer afterwards the empty partition will not do much good.

The only option is to throw out the second hdd, put the dvd drive back in the notebook, install windows via boot camp and do the fw upgrade. Alternative: Find a windows pc, rp out the f120 from the notebook and do the fw upgrade there.

Linux would not help. Same problem. Legacy OS. However that might boot with rEFIt. Never tried.

Are you sure you can't install windows over USB? http://gizmodo.com/#!5257386/how-to-install-windows-7-on-almost-any-netbook

"

• Mac OS X (courtesy of Ubuntu, funnily enough):

1. Open a Terminal (under Utilities)

2. Run diskutil list and determine the device node assigned to your flash media (e.g. /dev/disk2)

3. Run diskutil unmountDisk /dev/diskN (replace N with the disk number from the last command; in the previous example, N would be 2)

4. Execute sudo dd if=/path/to/downloaded.iso of=/dev/diskN bs=1m (replace /path/to/downloaded.iso with the path where the image file is located; for example, ./windows7.iso)

5. Run diskutil eject /dev/diskN and remove your flash media when the command completes (this can take a few hours on slower drives)"

one more link for you:

https://help.ubuntu.com/community/How%20to%20install%20Ubuntu%20on%20MacBook%20using%20USB%20Stick

I am running into this: http://forums.macrumors.com/archive/index.php/t-928907.html

I will give a boot disk a try. If Hiren or alike boot from a stick and the firmware upgrade tool works with that it would be the perfect solution for future upgrades.

I'm not experienced with Bootcamp, but what if starting Windows installation with parallels (or vm ware fusion) to windows partition, when it reboots first time, reboot it using bootcamp instead of parallels. Shouldn't it continue where it left? At this point installation dvd is not needed anymore

Or is it somehow possible to copy Windows repair disk to windows partition and boot from there? Then use command prompt to execute the firmware upgrade.

Or get the 100MB repair partition from windows machine and clone that to the Windows partition?

The firmware update utility for the force drive is not cmd it is gui based. If it was DOS executable that would make things a lot easier.

The best thing to do is to get a working windows installation and move it to a partition of the drive then boot it from there. You would need an entry in your boot manager, grub or whatever though.

The firmware update utility for the force drive is not cmd it is gui based. If it was DOS executable that would make things a lot easier.

 

The best thing to do is to get a working windows installation and move it to a partition of the drive then boot it from there. You would need an entry in your boot manager, grub or whatever though.

There is GUI in Windows repair, but no explorer. I haven't tested this, but it should possible to execute the update utility using cmd prompt, or from task manager, just copy the files to the windows partition before.