TRIM Support in Mac SSD

dm_dimon wrote:

let it be a well-thought prediction.

There are no third-party trim support in DP1-DP4 and any intermediate builds. There are no any technical problems to enable in since 10.6.6 or 10.6.7. So only possible conclusion - it's Apple policy.

I think for now it's the only way for Apple to get some advantage for Apple-branded SSD's over next-gen aftermarket choices. I'd expect 3-rd party TRIM support coming inline with next iteration of Apple-branded SSD's, not before that.

(BTW, they are not "Apple-branded" SSD's, but just sourced OEM components which Apple "allows" TRIM to be enabled for when shipped inside new machines. But I get what you mean ;-)

Anyway, are the SSD's Apple has sourced and used in its current machines not as good as other SSD's one could get from third-parties, then?

The only thing (I think) I understand, is that there are two competing philosophies for keeping an SSD working to its best:

(1) TRIM.

(2) Over-provisioning. Where say 7% (or even upto 28% for SSD's used in RAID usage) of the SSD gets appropriated for clean-up duties. [eg. OWC's current drive range.]

The latter was the main way but it uses-up the valuable drive space so is not the better of the two ways (ie. a 256GB SSD is thus only a 240GB SSD, as 7% of it's space gets used for the "over-provisioning" tidy-up stuff). Hence TRIM is the preferred method if you have a choice, so by Apple only turning this on for their own supplied drives (and without users using the non-Apple TRIM Enabler), they thus have the advantage you mention?

Anyway, are the SSD's Apple has sourced and used in its current machines not as good as other SSD's one could get from third-parties, then?

not "not as good", just "not as fast" for given amount of money. But with trim _disabled_ - in long term usage or under really heavy load any "other" SSD will degrade in speed so anyone can say that: "in long-term and under heavy use apple's ssd are best" and that will be true 😉

BTW not over-provisioning matters but idle garbage collection.

And _theoretically_ there are usage patterns when trim will slow down drive and shorten it's lifespan. I'd say if you have SF2xxx -based (or latest Intel) SSD _AND_ have a lot (20-30%) of free space on drive _AND_ do NOT have a heavy load of (uncompressible) write activity - you (I think) don't benefit from trim enabled

But if you have some mid2010-2009-earlier SSD - trim is your's definite friend.

Just for clarification on this. Os X Lion is being released in July, which is just days away, is it not? And if that's the case I dont think Os X Lion would still be an intermediate build version. If its to be released within days would they not have the final version already completed?

Anyway, are the SSD's Apple has sourced and used in its current machines not as good as other SSD's one could get from third-parties, then?

Apple's ssds are nowhere as good as ssds like the Ocz's vertex 3s or Intel's x25-Es. Those ssds are two of the best of all ssds. With that being said though, Apples ssds are still plenty fast. Even faster than the worlds fastest HDDs.

actually they're just ordinary 2009-mid2010 SSDs. mean apples.

And as an owner of X25 I can tell you that it's far from best. Slow on writes even for 2010 - and now already 2011

dm_dimon wrote:

actually they're just ordinary 2009-mid2010 SSDs. mean apples.

And as an owner of X25 I can tell you that it's far from best. Slow on writes even for 2010 - and now already 2011

Well, I said x25-e NOT x25. The x25-e is much faster than the x25 and apples SSD.

see: http://www.xtremesystems.org/forums/showthread.php?208896-Intel-SSD-(X25-E-amp-X -25M)-RAID-0-Benchmarks

Also, if the x25 is slow on your computuer then I would blame Apple NOT the drive itself. Because those drives are not slow on Pcs that have trim enabled.

Thank's LexSchellings! Helped me!

to any interested - ie especially for owners of SF2xxx based SSDs

repeating here what I told on OWC

trim, issued to drive, should have as an argument list of blocks to clean. It is that same list that OS uses to mark as free after deleting file. As we assume that OS can delete files from drive correctly – it can form that list correctly. No more, no less. No additional errors.
on trim vs GC – one difference – only OS itself knows exactly what is deleted.
And one more thing )
when GC is walking over drive, analyzing and optimizing data, it walks with read+write+analyze speed – ie not very fast. mean at least dozen(s) of minutes for drive – so it gives you deferred result
I’m trying to measure it myself right now, but it looks like trim crawls over drive much, much faster. Like probably 1000 times faster at least – so it gives you almost immediate result

So, in tight situations trim looks preferable to any kind of GC. But if you have spare place on drive enough – GC can outperform trim if well implemented.

From all I know, SF2xxx GC is implemented very well.

from minimal analysis you can get that SF2xxx heavily relies on internal compression. And in this case trim block list correspond to nothing on die level - so for run trim command, controller have to decompress some information and then recompress and write it back, so instead of really fast trim we have same execution speed as for GC (actually lower as GC runs read-workout-write, trim runs read-decompress-workout-compress-write), so yes, trim will definitely slow down SF2xxx - based SSDs and any other that uses controller-level compression.

So, TRIM on SF2xxx-based SSDs will slow them down. Not due to trim implementation in mac os, but due to controller internal logic.

I'd recommend:

IF you see loss of drive speed - let it idle for night

ONLY IF that will not help - enable trim, erase free space from disk utility, wait like an hour or even more, disable trim

Correction.

You should NOT use trim on SF2xxx - based controllers, basically - probably on any controllers with internal low-level compression.

Cos ACTUALLY IT WILL NOT WORK

Due to storing data as compressed stream, such controllers have nothing in common with list of block to erase.

They store data say as one big zip, with correct internal structure, and transparently compress/decompress that as needed. All free blocks automatically goes after the end of zip and can be perfectly determined by controller itself - and thus cleaned. So TRIM will give you absolutely no benefit on such a drive.

Furthermore, TRIM is in SATA standard set, and result of trim command is defined in said standard. So controller HAVE TO imitate trim inner workings - to conform to SATA standarts. So issuing trim command on some chunk of data you you forcing controller to read-decompress-imitate result-compress-write - just slowing down and wearing your drive.

Thats it. SF 2xxx does NOT need trim, they need trim disabled to fast work and long life.

I'd recommend Win7 users begin their search for "trim disabler" )))

The recommendation to not enable TRIM on SF2xxx based controllers… I assume that also applies to SF1200 controllers. Can anyone confirm?

I've been not interested in 1200's (I was far more impressed by Micron-based C300), but afaik GC in them is not good enough to live without trim. Try to find some testing of say Vertex2 on Anandtech. Dunno how it was implemented and how efficient it is.

Buy an OCW drive. The sandblast (or sand-something, I forget) firmware performs trim-related stuff on its own; trim is not necessary and in fact may slow down or make it less reliable.

I have seen no data to suggest than enabling TRIM on SSDs will make them slower or less reliable. Is their a study or test you are referencing, or is this a personal opinion?

Also I believe the "trim-related stuff" you are reffering to is called garbage collection. This does not take the place of TRIM support and will not prevent slow downs after regular use of non-TRIM-enabled SSDs.

OWC makes good products in general, but their SSDs are just rebrands with a preimium for the OWC name. I would reccomend going with a Crucial M4 Series SSD or a Corsair Force Series GT SSD. The sustained write speeds of these drives blow OWC's SSDs out of the water.

dm_dimon wrote:

let it be a well-thought prediction.

There are no third-party trim support in DP1-DP4 and any intermediate builds. There are no any technical problems to enable in since 10.6.6 or 10.6.7. So only possible conclusion - it's Apple policy.

I think for now it's the only way for Apple to get some advantage for Apple-branded SSD's over next-gen aftermarket choices. I'd expect 3-rd party TRIM support coming inline with next iteration of Apple-branded SSD's, not before that.

Actually I used the trim enabler on my Corsair SF12xx controller based ssd, and indeed trim made the SSD go to a crawl and made everything generally unreliable. I personally however still think, either Windows simply ignores it and does not send any trim commands, or Apples trim implementation does not work on the disk.

Either way i have had the disk now for half a year with trim being turned off, it still is as fast as it used to be, no noticable difference, trim not really is needed, and given it is a notebook hd, it idles often enough to have the gc doing its task.