TRIM Support Enabler

[Weaselboy]

For exampel:



or?

I think you need to go back and reread bobics post and also read the rest of the posts here. bobic's XBench test difference was well within the normal variance of XBench tests and not indicative of a zero erase causing a problem. Try it yourself. Run three Xbench tests in a row and you will never get the same result.

This thread is full of people who did a secure erase in Disk Util and noticed a performance increase. They even posted their results. I believe you are mistaken.

 

[ztrafe]

I think you need to go back and reread bobics post and also read the rest of the posts here. bobic's XBench test difference was well within the normal variance of XBench tests and not indicative of a zero erase causing a problem. Try it yourself. Run three Xbench tests in a row and you will never get the same result.

This thread is full of people who did a secure erase in Disk Util and noticed a performance increase. They even posted their results. I believe you are mistaken.

You are right

 

[Weaselboy]

Just installed the patch on a 2011 13" MBP with a 120GB Intel 510 SSD. Everything worked perfectly and system profiler now shows TRIM enabled.

Did a Disk Util "Erase Free Space" with before and after XBench tests and did not notice any difference in results. I suspect this is because the drive has only been in use a couple weeks and very lightly used, so very little of the SSD had ever been written to to begin with.

Cindori>> Great utility. Nice touch the way it gives you feedback what it is doing as the patch runs. Donation sent.

 

[KPOM]

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

If you install the patch, then TRIM will be enabled, and it will say "TRIM Support: Yes."

 

[Bauss]

Why are so many people Erasing free space on their SSDs? This was not how TRIM was meant to work.

TRIM works passively, at a lower level than your OS, to inform the controller of what blocks are marked as unused, and can simply be written to, as opposed to invoking a read-erase-modify-write cycle.

So unless you enjoy writing zeros to your drive for no reason, and further wearing out your flash, I'd avoid erasing free space. It doesn't help.

 

[Weaselboy]

Why are so many people Erasing free space on their SSDs? This was not how TRIM was meant to work.

TRIM works passively, at a lower level than your OS, to inform the controller of what blocks are marked as unused, and can simply be written to, as opposed to invoking a read-erase-modify-write cycle.

So unless you enjoy writing zeros to your drive for no reason, and further wearing out your flash, I'd avoid erasing free space. It doesn't help.

You are correct once TRIM is enabled. But this does not free up the space that was written to before TRIM was enabled. Thus the wipe with TRIM to reset every cell on the drive as unused.

Look at some posts in this thread from users with drives that have been in use sometime and their write speeds went up significantly by erasing free space to reset TRIM.

 

[Hellhammer]

TRIM works passively, at a lower level than your OS, to inform the controller of what blocks are marked as unused, and can simply be written to, as opposed to invoking a read-erase-modify-write cycle.

No. This is straight from AnandTech:

When you delete a file, the OS sends a trim command for the LBAs covered by the file to the SSD controller. The controller will then copy the block to cache, wipe the deleted pages, and write the new block with freshly cleaned pages to the drive.

Now when you go to write a file to that block you’ve got empty pages to write to and your write performance will be closer to what it should be.

So unless you enjoy writing zeros to your drive for no reason, and further wearing out your flash, I'd avoid erasing free space. It doesn't help.

34nm flash has 5000 write cycles so you have nothing to worry about. Your NANDs will most likely lose their charge before you wear them out by writing. Many users have tried that and it has improved their performance, so it does work. It may not be what TRIM was initially meant for but it serves the purpose there too.

 

[ActionableMango]

Why are so many people Erasing free space on their SSDs? This was not how TRIM was meant to work.

TRIM works passively, at a lower level than your OS, to inform the controller of what blocks are marked as unused, and can simply be written to, as opposed to invoking a read-erase-modify-write cycle.

So unless you enjoy writing zeros to your drive for no reason, and further wearing out your flash, I'd avoid erasing free space. It doesn't help.

Based on my very limited understanding, I'd agree with you.

Also, I'd further state that modern Sandforce controllers are supposed to have their own internal garbage collection methods, making TRIM unnecessary.

And yet people are posting results that show writing zeros does speed things up. And people are posting results showing that Sandforce controller SSDs still benefit from TRIM.

 

[andrer]

So unless you enjoy writing zeros to your drive for no reason, and further wearing out your flash, I'd avoid erasing free space. It doesn't help.

Note that Disk Utility, to write zeroes to the drive, actually creates a temporary .sparseimage, then proceeds to write zeros to it, and deletes that file. So in the end, when it deletes the file, one can assume that a TRIM command is sent to all those sectors the file was occupying.

 

[Cindori]

Note that Disk Utility, to write zeroes to the drive, actually creates a temporary .sparseimage, then proceeds to write zeros to it, and deletes that file. So in the end, when it deletes the file, one can assume that a TRIM command is sent to all those sectors the file was occupying.

perfect explanation!

 

[bobics]

I think you need to go back and reread bobics post and also read the rest of the posts here. bobic's XBench test difference was well within the normal variance of XBench tests and not indicative of a zero erase causing a problem. Try it yourself. Run three Xbench tests in a row and you will never get the same result.

This thread is full of people who did a secure erase in Disk Util and noticed a performance increase. They even posted their results. I believe you are mistaken.

All four of my XBench passes before zeroing free space were faster than all six of my passes afterwards. It's statistically possible but unlikely. At best, TRIM doesn't help much if at all in my setup. I've had my SSD for about 9 months, with heavy use (I'm a developer) and at least 80% full. Probably dumb of me to try an unsupported feature but I'm an eager beaver when it comes to tech (I did backup beforehand).

 

[archangel37]

OWC Mercury Slower for some things...

Has anyone else with a OWC Mercury SSD noticed a slow down on some day to day stuff? I've noticed that installing updates to Webkit/Safari are far slower. In addition, deleting the trash takes far longer than it used to take. Synthetic benchmarks and read/writes are generally up, but I'm still not sure if this is a win-win, at least for my OWC.

I'd love to hear what others with OWCs are experiencing with deleting trash, installing applications, and the works.

 

[leowyatt]

Cindori can you add the terminal commands from post 86 to the first post?

 

[Cindori]

Cindori can you add the terminal commands from post 86 to the first post?

the patch already runs those commands. I don't see why people are noticing difference from running them manually again

 

[tkermit]

It might be helpful if you published what exactly your program is doing.

And not to put down your efforts, Cindori. But I also think a bit more credit should go to "Viktor D.". As far as I can see, he is the one that actually researched this "hack", if you want to call it that.

 

[leowyatt]

the patch already runs those commands. I don't see why people are noticing difference from running them manually again

I did the erase free space and had to run the commands again because my air was taking around 33 seconds to boot up instead of the usual <15

 

[jenzjen]

For me, no change to boot and shutdown times, but this was expected since my SSD is just the boot drive and sees very little large file transfers. I also did a true secure erase about 3 months ago.

It is still worth it, though, since I now have TRIM enabled.

Here are my results on my Intel 80GB G2:

BEFORE INSTALL
15s to white screen, 35s (total) to login
9s to shutdown

AFTER INSTALL
15s to white screen, 35s to login
9s to shutdown

THEN, I DELETED FREE SPACE, RE-BOOTED
15s to white screen, 54s to login
21s to shutdown

THEN, I RE-PATCHED, RE-BOOTED AND LET THE MACHINE SIT IDLE FOR ~10 MINUTES
15s to white screen, 35s to login
9s to shutdown

 

[jonnymo5]

Worked for me! Much appreciated for taking the time to write this.

 

[dyn]

Note that Disk Utility, to write zeroes to the drive, actually creates a temporary .sparseimage, then proceeds to write zeros to it, and deletes that file. So in the end, when it deletes the file, one can assume that a TRIM command is sent to all those sectors the file was occupying.

And that is exactly why the entire procedure is completely useless. You're writing something to the ssd, then removing it. The only thing TRIM then does is remove that file from the nand. If you benchmark it so you can see the performance degradation and TRIM actually restoring it to the situation before the secure erase this will only proof TRIM is working. It wil not restore the entire drive to the factory defaults. For that you need other tools such as a linux livecd with hdparm (hdparm can issue the trim command for the entire drive).

Take a look at jenzjen's post: this shows exactly what I mean. The performance got restored eventually by letting it sit idle. TRIM does not work when being idle but there is another mechanism that does: garbage collection (gc) aka nand launderer.

 

[Hellhammer]

And that is exactly why the entire procedure is completely useless. You're writing something to the ssd, then removing it. The only thing TRIM then does is remove that file from the nand. If you benchmark it so you can see the performance degradation and TRIM actually restoring it to the situation before the secure erase this will only proof TRIM is working. It wil not restore the entire drive to the factory defaults. For that you need other tools such as a linux livecd with hdparm (hdparm can issue the trim command for the entire drive).

It will erase the blocks which will allow you to write to them straightaway. As long as the block is empty when you are writing to it, it will write at full speed. Otherwise you first need to read it, then erase and after that write.

There isn't much point in erasing the blocks that are in use, as you aren't going to write to those blocks anyway. Erasing free space is pretty much as good and easy it will get. A secure erase of the whole drive might yield a marginal difference in benchmarks.

 

[nastymrx]

For me, no change to boot and shutdown times, but this was expected since my SSD is just the boot drive and sees very little large file transfers. I also did a true secure erase about 3 months ago.

It is still worth it, though, since I now have TRIM enabled.

Here are my results on my Intel 80GB G2:

BEFORE INSTALL
15s to white screen, 35s (total) to login
9s to shutdown

AFTER INSTALL
15s to white screen, 35s to login
9s to shutdown

THEN, I DELETED FREE SPACE, RE-BOOTED
15s to white screen, 54s to login
21s to shutdown

THEN, I RE-PATCHED, RE-BOOTED AND LET THE MACHINE SIT IDLE FOR ~10 MINUTES
15s to white screen, 35s to login
9s to shutdown

Same here. Weird. Mbp 5.3 Intel 160GB 2Gen

 

[dyn]

@Hellhammer: Erasing free space is only good if there actually was any data in that space. This will be overwritten the way andrer explained. Upon deletion TRIM will clear those cells. There isn't much chance that you'll run into this, especially not since every ssd does GC. Most drives are already up to speed. I'm not debating if TRIM works or not, it should do the same thing as GC does. Since there is little to no performance difference between GC and TRIM I'm not going to use the TRIM enabler. There simply is no benefit.

 

[Cindori]

It might be helpful if you published what exactly your program is doing.

And not to put down your efforts, Cindori. But I also think a bit more credit should go to "Viktor D.". As far as I can see, he is the one that actually researched this "hack", if you want to call it that.

Read about it here:
http://www.groths.org/?p=308

It was not discovered by Viktor D, it was discovered by russian / german users.

Users on macbidouille then discovered an even better way to do it.

Anyway it was Macbidouilles guide and new hack method I used, and you should be able to see my credit to Macbidouille and their users in the original post and my website...
Theres also a link to their english version, Hardmac, in the application itself.

I did the erase free space and had to run the commands again because my air was taking around 33 seconds to boot up instead of the usual <15

I just did the erase too and had very sluggish system! 45sec boot!
I will post the terminal commands at first page and urge everyone to use them if you Erase Free Space.

 

[jenzjen]

I will post the terminal commands at first page and urge everyone to use them if you Erase Free Space.

Or, from my experience, just re-run the patch after both erasing free space and rebooting.

 

[xgman]

Worked great on by Snow Lep drive. Never was slow upon reboot, before or after patch and scripts. Also seemed to work on my Lion drive but I had to back up the file manually there due to some error in the backup process. Also ran the suggested terminal scripts to tidy up afterwards.