Xbench’s disk test reported no significant difference following each of the erase free space runs. My boot time has worsened by about five seconds.

This “tip” is not recommended from my tests.

Trim support Yes

http://www.bit-tech.net/hardware/apple/2010/07/01/mac-ssd-performance-trim-in-osx/comments/2

I haven’t verified this, but if it’s correct, then this tip may not accomplish anything, and may explain some decreased performance in some of the comments here. (I seem to vaguely remember this as being true, when working with controllers with flash memory.)

So can this trick (erasing free space to 0) really work as a trim replacement? YES! Contrary to what people claim here, it can! But it depends a lot on how your SSD works.

E.g. if your SSD tries to be clever, it may not always rewrite a whole block, just because a single byte is changed. It may first look at the block, if the change is possible WITHOUT rewriting. E.g. changing the byte 192 to 206 is possible without rewriting. 192 has two bits set and 206 has the same two bits set + another three not set in 192. The SSD can just swap the three extra bit and that’s it. See above, changing bits from 0 to 1 is possible on a per bit basis, there is no need to rewrite a whole block, unless the “write operation” causes any bit to flip from 1 to 0; *ONLY* in that case a block has to be rewritten. So by setting blocks of free space to all zero, there is no write operation that would every force a block rewrite (a write operation will then be 0 -> 1 or 0 -> 0, but certainly not 1 -> 0). Only a rather dumb SSD would rewrite a whole block even though unnecessary (especially since this degrades the lifespan of the whole drive).

Another reason why this trick might work: As I said at the top, initially all bits are set to 0, remember? Well, if you make a write operation, that sets all bits of a block back to zero, how is this block different to a really “unused” block (one that has been marked unused by trim)? Correct answer: NOT AT ALL! So a clever SSD could automatically mark a block as unused (the same way TRIM does it) the moment it sees that all bytes of a block are now zero, since it makes no difference for the SSD, the controller or the OS; nobody would even notice this change (a kind of automatic TRIM).

BTW, it is rather funny that some people here claim, that overwriting a block by all zeros is bad, because it causes unnecessary write operations to SSD. What do you think does TRIM? It erases the BLOCK, that means it overwrites it with all zeros. The only difference is, that TRIM erases the block and then marks it as unused. Overwriting it with all zeros might cause the block to be erased (the very same thing that TRIM does) and not being marked as unused; but there is no extra write operation (changing a block from all zero to all zero is no write operation, it’s a NOP, a No Operation, just do nothing), there is only a single block erase, the same operation, either triggered by a WRITE or by a TRIM.

There are only three reasons why the trick will not work: First one, you have a cheap SSD that is dumb as toast, thus in won’t recognize all zero blocks and will perform unnecessary block rewrites. In that case don’t worry about you OS X missing TRIM, this SSD will probably die before a TRIM support would have shown an improvement. Second reason, who says that erase free space writes zeros? Ever clicked on security options? There you can select how DATA is to be overwritten and all zeros is just one option. However, these options say they are for erasing data (the Erase button, not the Erase Free Space button), so I have no idea how Erase Free Space actually overwrites the free space (where does it say it uses 0 for that?). Choosing anything but 0 will of course make things a lot worse. And finally, the thing most people like to forget: Your SSD may not be based on NAND, but on NOR gates. NOR gates have a value of 1 by default and can only be changed from 1 to 0; a change from 0 to 1 is only possible for a whole block again. If you have a NOR SSD, you had to overwrite all bytes with 255 and not with 0.

Of course TRIM support is great; the SSDs doesn’t have to be “that” smart anymore, the OS will assist it; there is no need to worry if NAND or NOR (TRIM always does it correctly) and so on. However, claiming that the trick described above cannot work, will not work, or is even bad for your SSD, is partially incorrect or even utterly nonsense. The trick is not guaranteed to work, since it depends on many factors, but it won’t harm your SSD or make things even worse, if they are are already really bad. If your feel you SSD performance has gone to crap, try this trick. Either it will make your SSD better again or it will do nothing.

Best,
John

I was left with 0KB free. Rebooted and OS X wouldn’t start – Startup Disk is Full. Had to boot into single user mode and delete stuff I would rather not have.

http://diglloydtools.com/disktester.html

After speending hours for tweaks this blog was best i found.

1st link is follow up from previous post, you should read both links.

http://blogs.nullvision.com/?p=357

http://blogs.nullvision.com/?p=275

Good luck!!!

douz: I’m not entirely sure why, I just know that zeroing out and a large “secure empty trash” slows my drive down.

Now what I think what it does is it creates a file of the exact same size of the free space and writes the zeroed out data to that, then saves it over the free space. So now the OS instead of recognizing the free space as an area to write over it has to contend with the zeroed out file. (This is just my theory of what goes on, I’d love to see an article with the specifics.)

Regarding native TRIM support and necessity, with Apple moving in the direction of all flash-memory, if it was a needed feature don’t you think they would prioritize development? This is what makes me skeptical that it is needed at all.