SSD Trim Support like in Windows 7

Odd for sure, and the issues from last fall with SSDs is past, and even Crucial had some trouble.


"WHICH DRIVE SHOULD I ORDER FOR MY NEW MACBOOK PRO?"
http://www.barefeats.com/mbpp19.html

TRIM report Macs and what you should know and be concerned.
http://macperformanceguide.com/SSD-RealWorld-Seasoning.html

I've seen people use a number of SSD brands incl. Corsair P256, and there are new models and reviews almost daily.

http://techreport.com/articles.x/18757
http://www.anandtech.com/tag/storage

OWC Mercury Extreme Enterprise-class RAID-ready SSD
http://macperformanceguide.com/Reviews-SSD-OWC-Mercury_Extreme.html

Linux supports trim with hdparm, but that is still a work in progress:
http://www.google.com/search?client=safari&rls=en&q=trimlinux+ssd+hdparm9.28&ie=UTF-8&oe=UTF-8

http://www.ocztechnologyforum.com/forum/showthread.php?60882-wiper.sh-discussion -thread-%7BLinux-TRIM-tool%7D/page14

and of course it won't compile as is on OS X because of the file system differences.

Of course one good reason for Apple to shy away from implementing it is, there is no standard way
of implementing it. If it were included in the Sata command set (which it is not), it would be easy
to write a driver.

At $500 + per drive (big enough to be of any use) you would think the drive manufacturers could
afford to hire someone to write drivers.

I believe the manufacturers need to implement their own solution since they can't agree on how it
should be done anyway, and what about the guys running Raid setups?

I believe the whole trim thing is a masterpiece of "garbage collection" in itself.


Kj ♘

nachotech wrote:
orthorim -- without TRIM, an SSD has no way to know if a file has been deleted. All it sees from the SATA interface is READs and WRITEs. The SSD's idle time garbage collection is for it to reorganize its own free space (this is space that is overprovisioned, e.g. a 160GB drive might actually have 200GB of NAND flash storage space - this extra space is to help it improve write performance).

The bottom line is that for optimal performance, we need Apple to implement a TRIM mechanism within the HFS filesystem.

Alternatively, an SSD vendor could provide their own low-level utility that we could run occasionally to help the drive know about blocks belonging to files that have been deleted.

It appears that there is more going on with the idle garbage collection in some of these drives and OS X. Take a look at the benchmark results in this link:

http://www.hardmac.com/news/2010/05/06/even-without-support-for-the-trim-command -ssd-flies-on-mac-os-x

The TRIM command is not yet an ATA standard and it appears to add overhead to each transaction, whereas idle GC makes use of downtime. It's a use case thing, if you need non-stop transactions then you wouldn't be using SSD, and even if you RAIDed SSDs, TRIM doesn't work with RAID on any system, GC is the only way to go.

KJK555 wrote:
Linux supports trim with hdparm, but that is still a work in progress:
http://www.google.com/search?client=safari&rls=en&q=trimlinux+ssd+hdparm9.28&ie=UTF-8&oe=UTF-8

Perhaps the hdparm TRIM support is a 'work in progess,' but the Linux kernel has supported TRIM since 2.6.33.

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.33

Of course one good reason for Apple to shy away from implementing it is, there is no standard way
of implementing it. If it were included in the Sata command set (which it is not), it would be easy
to write a driver.

This is an incorrect statement. The ATA TRIM command is a standard that is currently being finalized. It is close enough to final for Windows 7, Server 2008R2, and FreeBSD v9+. Apple probably just didn't think about it, and haven't had the time to implement it.

http://en.wikipedia.org/wiki/TRIM#ATA_Specification

Message was edited by: smbrannon

1.) TRIM not being an "ATA standard" is not a valid response, or excuse for that matter. The 802.11n was in draft stage for SEVEN YEARS...does that mean that in that time period no one should support it or release products that use it? Of course not. The specification is written and it is standardized acorss drive manufacturers. The information is freely available -- it's not yet ratified because there are other things being added to the spec as well. They can't just ratify a spec for ONE updated command...

Add this to the fact that every other modern OS on the planet supports TRIM and has for almost a year now -- Apple is starting to look bad, but no one seems to care...10.6.4 is here and still no TRIM support.

2.) "it appears to add overhead to each transaction" -- completely 100% false. I suggest you do some more research on the topic before posting in the future.

Unfortunately I replyed to this thread
http://discussions.apple.com/thread.jspa?messageID=11570055&#11570055
before I read this one.

I share "nachotech's" oppinion, that there is no way the ssd-controller can reconize unused blocks of a file system, without being notified in some way. I'm waiting for KJK555's answer, if zeroing out unused blocks can help.

If the GC@idle is the best approach today, wondering if a reboot into a pre-boot state (rEFIt) will speed up some things (just power on), while ensuring that no OS (services, logs nor time maschine) is constantly writing to disk.

THX.

hey guys, i read this comprehensive review (although not fully conclusive) it bring up some pretty good questions.

http://www.bit-tech.net/hardware/apple/2010/07/01/mac-ssd-performance-trim-in-os x/1

although this was tested on an out-of-date macbook air it still looks good on the MAC SSD front.