Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
hrm. Seems to have slowed down startup and shut down times for me. Don't have a baseline to go off of, but my boot time is about 47 seconds (defined as button press to when thunderbird and firefox appear on the screen), which seems to be 15-20 seconds longer than before. Also, on shutdown, I'm getting a little spinning wheel (not the color wheel, the other one...similar to the spinning wheel on iOS) that I definitely wasn't ever getting before...shutdowns used to be less than 7 seconds, now they're closer to 15ish. Ideas?

Honesty I don't know for sure but those are the same symptoms I was having until I applied the patch, v1.1. Also, I just checked my startup/shutdown times and they're still back to normal. I would try applying the patch again or using the Terminal commands.
 
do i need to clean install SL in order to use it? or do i just click the PATCH button with my current installation?
 
Hello,

First off thanks Cin for your work in this! MY average XBench score went from 240 to 285 on my Intel 80GB G2.

Second, I have a different boot time problem. Here it is in a nutshell. (I've tested each boot time test 4 times.)

Boot time before TRIM patch: 44 seconds.
Boot time after Trim patch: 44 seconds.
Boot time after erasing free memory: 58 seconds.

Why?

Thanks

Loa



a couple of weeks ago this happened to me when erasing free space on my 60Gb OWC SSD.

I contacted their tech support and the fellow suggested reinstalling OS X. Not an erase & install, just reinstall. I did. After 'erasing free space' boot times dropped to 47 seconds. Once I reinstalled OS X, boot time went back to 15 seconds. The OWC techie suggested something may have become corrupted during the erasing of free space, but he had no idea and claimed my problem was a first.

fwiw, I installed this patch on my mid 2010 13" MBP with 60GB OWC SSD. Boot times have actually become 2 seconds faster. Boot times are a blazing 13 seconds from the time I press & release the power button.

amazing.

and, obviously, profiler now states my MBP has TRIM support.

thanks :)
 
Not sure whether this is actually a full TRIM - I think it's not.

In the Linux world there's support for a 'real' Secure Erase, ie. telling the SSD to let go of its entire contents, restoring to new. This is the method I used to use before Cindori got busy:

https://forums.macrumors.com/threads/841182/

A little bit more complicated, but it's an instant restore to new. The Disk Utility method isn't, as far as I'm aware. But I may be wrong and a lot of people including myself wasted a lot of precious time in the past ;)

No go enjoy your blazing SSD speeds !!

Now that there is TRIM, deleting or erasing any space/file should send a message to the SSD to actually erase the block. Before TRIM, the method you linked was the only way because when you deleted something, the OS did not tell the SSD to really get rid of it.
 
I used the TRIM Enabler and it worked and enabled the TRIM support on my SSD but after enabling it appears to be very sluggish and slow. I'm using OWC Mercury Extreme Pro SSD 240GB btw. After restoring the kext from Time Machine, it went back to fast again. I was wondering if this problem only applies to OWC SSDs?

Mine did bootup slow a few times, but those terminal commands listed in a previous post should fix that.

What is the problem with your OWC SSD? Slow boot, slow app launch?

BTW, I have the 120GB OWC SSD and its running fine with TRIM enabled.

It worked for me!!!
Thanks

I haven't seen any significant improvement in performance yet.
Xbench score is 205.9 (before Trim) and 204.7 (after trim)

Hoping for long term benefits:)

Capacity: 240.06 GB (240,057,409,536 bytes)
Model: OWC Mercury Extreme Pro SSD
Revision: 343A13F0

Which Macs are you using guys?

Did someone using an OWC's unit got TRIM to work properly? hellozero did you updated your unit firmware?
 
Last edited:
Not sure whether this is actually a full TRIM - I think it's not.

In the Linux world there's support for a 'real' Secure Erase, ie. telling the SSD to let go of its entire contents, restoring to new. This is the method I used to use before Cindori got busy:

https://forums.macrumors.com/threads/841182/

A little bit more complicated, but it's an instant restore to new. The Disk Utility method isn't, as far as I'm aware. But I may be wrong and a lot of people including myself wasted a lot of precious time in the past ;)

No go enjoy your blazing SSD speeds !!

I happily updated that post you linked to on Secure Erase to note that in the presence of TRIM support, that procedure is no longer necessary. It is still required occasionally for guys like me running SSDs that lack TRIM support (eg Intel G1).

At any rate, that was effectively forcing a TRIM of the entire drive (both full and empty blocks), marking all NAND blocks free and was the only solution to do so. And for the record, its worth noting that any other method of secure erasing a drive by clearing data or overwriting free space, etc is not the same as these methods simply manipulate the bits in the cells, not release the NAND.
 
I am using the late-2010 MBA with the original 128GB SSD.

I've updated to 10.6.7 and System Profiler currently says "TRIM Support: No"

Do I need this?

thanks
 
didn't help for me... somewhat worse performance actually

I have a Late 2008 15" Unibody Macbook Pro with a 120 GB OCZ Agility 2 SSD. Here are my XBench results (best of 2 runs after a reboot):

220.62 - initial reboot of my stock system
246.93 - upgraded my OCZ firmware from 1.20 -> 1.32 (latest)
242.97 - ran TRIM tool 1.1 (latest as of 3/29 12 AM PST)
232.71 - after zeroing free space
233.94 - after running terminal commands
234.51 - after removing TRIM tool

It looks like zeroing free space caused performance to degrade, and as you can see, running the terminal commands after that didn't help.

Since running the tool didn't seem to help (and may have made things worse), I'd rather avoid the voodoo of enabling a feature Apple intentionally left out. It appears the Agility 2 has garbage collection anyway.
 
Last edited:
Had to uninstall it from my machine: MacBook pro 15 2011 with Intel 320 120GB.

Over night the system hung at 4 am and when I came to use it this morning at 7:45 was totally unresponsive. Since then has totally crashed 3 times so uninstalled and hoping that is the end of it.

Impossible to work when it needs to be forcibly rebooted every 30 mins!

Hopefully it will become useable for me soon.
 
Worked fine for my Corsair Force F120 Firmware 1.1 in a Macbook Pro 2011, 10.6.7

No issues at all. Boot time seems to be the same as before.

Mine has never been that full and is quite new but i did "erase space":

Drive Type Corsair CSSD-F120GB2

Before:
Disk Test 308.50
Sequential 187.02
Uncached Write 272.33 167.21 MB/sec [4K blocks]
Uncached Write 278.42 157.53 MB/sec [256K blocks]
Uncached Read 87.79 25.69 MB/sec [4K blocks]
Uncached Read 365.89 183.89 MB/sec [256K blocks]
Random 880.27
Uncached Write 1407.80 149.03 MB/sec [4K blocks]
Uncached Write 495.12 158.51 MB/sec [256K blocks]
Uncached Read 2804.49 19.87 MB/sec [4K blocks]
Uncached Read 686.13 127.32 MB/sec [256K blocks]


After

Disk Test 324.76
Sequential 196.07
Uncached Write 296.46 182.02 MB/sec [4K blocks]
Uncached Write 283.84 160.59 MB/sec [256K blocks]
Uncached Read 91.93 26.90 MB/sec [4K blocks]
Uncached Read 380.69 191.33 MB/sec [256K blocks]
Random 945.03
Uncached Write 1419.55 150.28 MB/sec [4K blocks]
Uncached Write 488.19 156.29 MB/sec [256K blocks]
Uncached Read 2456.10 17.40 MB/sec [4K blocks]
Uncached Read 932.25 172.99 MB/sec [256K blocks]
 
Just to confirm, the restore function in v1.1 works well.

I did however, have to force the MBP off when it needed to reboot (it hung just before it could restart).

Everything is running perfect now though, well done Cindori.
 
Last edited:
good job

To fix the slow boot try the following commands in terminal:

sudo chown root:admin /
sudo kextcache -system-prelinked-kernel
sudo kextcache -system-caches

Worked on my MBA 11" Ultimate.

this also fixed the slow boot on my mac pro 2010
 
Thanks, Cindori! I was afraid of that. The firmware update requires a Windows computer/installation, which I don't have.

Thanks again for taking the time to write this program, it's much appreciated!

Now would be a good time to use boot camp :)
 
I contacted their tech support and the fellow suggested reinstalling OS X.


Thanks for he suggestion, but my 44 seconds boot time has to be taken in context: my OS is on the SSD, but my Home folder is on a 4 disk RAID-0 set (internal), and you have to add the 4 HDs in eSATA external enclosures. So my Mac Pro has 9 drives to check and load.

I'm not worried about the length itself, just the fact that it jumped to 57 seconds. But now after running the terminal commands, everything is back to normal (44 secs).

Loa
 
2008 uMBP
2.53 ghz C2D,
8gb RAM,
Corsair C300 256gb SSD SATA 3

Best news this week. Now I'm not sweating Lion nor worried about screwing up my SSD!
 
Work great on my MBP with Intel X25

Thanks a lot to you,
Work great on my MBP with Intel X25 160gb...

PS. When I installed Lion and boot in verbose mode, I recognize that Lion 10.7 reading my SSD faster than 10.6.7. I don't know Lion using different method to accessing the Hard drive or not. Anyone see this?
 
Is there anyway to find a files starting block in a filesystem on the mac? e.g. like the hdparm method on linux.

I wanna do something like this:
http://www.ocztechnologyforum.com/f...-1.4-and-Linux&p=479503&viewfull=1#post479503

This way we can check if trim is working. would be great not having to relay on booting into linux.

Yes, just boot up with Ubuntu Live CD

1. Boot to OS X and create a tempfile to home dir
sudo dd if=/dev/urandom of=tempfile count=100 bs=128k

2. Load Ubuntu live cd, when in install screen press ctrl-f2 to go to console

3. Mount OS X disk
sudo mkdir /tmp/macosx
sudo mount /dev/sda2 /tmp/macosx

4. check the start sector of the tempfile
sudo hdparm --fibmap /tmp/macosx/Users/username/tempfile
copy the number under "begin_LBA" and use it in the next command

5. read the sector
sudo hdparm --read-sector 72276768 /dev/sda

it lists a page of hex code

6. Reboot to OS X and use finder to trash the tempfile and empty trash

7. boot back to Ubuntu live cd, when in install screen press ctrl-f2

8. read the sector again
sudo hdparm --read-sector 72276768 /dev/sda

now it displays zeros
 
To fix the slow boot try the following commands in terminal:

sudo chown root:admin /
sudo kextcache -system-prelinked-kernel
sudo kextcache -system-caches

Worked on my MBA 11" Ultimate.

Thanks, need to test that when I got back to home.

I googled the commands and found also another speedup tip: Clear the dynamic loader shared cache by booting one time to Safe mode

http://www.ubermediahd.com/blog/?p=223
 
How to trim an un-trimmed disc.
1: Install the SSD hack
2: Reboot
3: Verify TRIM-support
4: IF Yes: Just Copy a big file until the SSD-space is almost full, than delete the files you just created.

!= Dont use "delete free space" in the Disc utility, macrumors user´s has reported that it doesn´t work!
 
Last edited:
How to trim the disc.
1: Install the SSD hack
2: Reboot
3: Verify TRIM-support
4: IF Yes: Just Copy a big file until the SSD-space is almost full, than delete the files you just created.

= Dont use "delete free space" in the Disc utility because that not work!

Why do you say the Disk Util erase free space will not work? Others have reported it does and provided proof using HDParm.

All Disk Util does is create a giant .sparseimage file and enlarge that sparseimage until the entire drive is full. The same thing you are doing by making copies of a large file repeatedly.
 
Why do you say the Disk Util erase free space will not work? Others have reported it does and provided proof using HDParm.

All Disk Util does is create a giant .sparseimage file and enlarge that sparseimage until the entire drive is full. The same thing you are doing by making copies of a large file repeatedly.

For exampel:

It looks like zeroing free space caused performance to degrade, and as you can see, running the terminal commands after that didn't help.

or? :)
 
For exampel:

Might depend on the SSD. SF-based SSDs have fairly aggressive GC which may have an effect on the erase of free space. Intels have lousy GC and with them, that method has been very effective.

Your method is not any better though, as basically it is the same.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.