It's disappointing that this has been lacking, it's a very important feature for proper use of modern SSDs and it's been in Windows since late 2009 and Linux since early 2010.
Which so far as proven not to be so important, especially as Apple has historically been using SSDs very resilient to that issue (according to Anandtech's tests of the 2010 MBAs).
If you think an SSD can be "resilient to that issue" you don't understand the problem. From the Anandtech article you mention:
"Either the Toshiba controller is using over 12% of the total NAND capacity as spare area, or there's only 30GB of usable flash on the drive."
So they're lying about capacity to offset the need for TRIM. Who knows the long-term implications of that decision? I noticed the benchmark didn't saturate the drive to capacity before speed tests. Maybe they didn't mention it, sloppy either way.
Perhaps long term results aren't relevant; a frequent upgrade cycle is assumed. I suppose the average user is agnostic to the capabilities of their hardware, like you suggest.
There is no reason trim needs to be done in the OS. (Not that I know of any drive that does this, but it should be possible without any OS interaction.)
Prior to TRIM an SSD had to assume that any block that had ever been written was still in use by the filesystem. If you end up creating lots of temp files, for example, the SSD will think that you are operating at capacity saturation regardless of actual usage. This can result in uneven wear leveling and excessive physical fragmentation which could decrease performance and useful lifetime of the drive. Additionally, it could increase the need for "write amplification" which also negatively impacts performance.
Without TRIM, there's no way for an SSD to know (without cheating) which blocks are considered free by the filesystem. Increasing the FTL free space allows an SSD to absorb more writes at full speed before needing to GC.
A SSD that understands NTFS and the other major file systems while "cheating" is not impossible. Also The TRIM command does not work on RAID volumes so there is plenty of room for improvement.
Sometimes you need to read more than just the first line to know what's going on.
"More recent SSDs will often contain internal idle/background garbage collection mechanisms that work independently of TRIM; although this successfully maintains their performance even under operating systems that do not (yet) support TRIM, it has the drawback of increased write amplification and associated increased wear of the flash cells.[4]"
This "resilience" is overrated; Apple's Samsung/Toshiba SSDs don't get much slower over time, but they start out slow to begin with. They're effectively pre-degraded.
The complaint is that Apple's lack of TRIM support impacts performance on their SSDs; the Anandtech article says that this isn't the case. The fact that their SSDs are slower than the competition is a separate argument.
"Because of the way that file systems typically handle delete operations, storage media (SSDs, but also traditional hard drives) generally do not know which sectors/pages are truly in use and which can be considered free space. Delete operations are typically limited to flagging data blocks as "not in use" in the file system.[5][6] Contrary to, for example, an overwrite operation, a delete will therefore not involve a physical write to the sectors that contain the data. Since a common SSD has no access to the file system structures, including the list of unused clusters, the storage medium remains unaware that the blocks have become available."
Uh, why would I be saying "yay, TRIM!" if I thought OS X already had TRIM?
Here, "blocks" is ambiguous. On a rotating HD, OS X does use the same physical blocks. On an SSD, OS X tries mightily to addresses the same "blocks" but the SSD might move this mapping to different physical blocks.
By doing this, OS X minimizes, as much as possible, the dirtying of "blocks" it doesn't have to, which means it puts the least burden possible on the SSD as it tries to do things like wear leveling.
3rd try. Please respond to what I'm actually saying.
Once the disk is full, "dirty" blocks have to be re-used. Clearing those for writing adds time and bandwidth overhead that slows down write performance.
So, the OSX "solution" is a temporary fix. However I'm pretty sure SSD write leveling behavior is standard across all other operating systems.
Blocks - memory address space sections? What's ambiguous about this term?
Actually, you said it earlier in the thread: the motherboard is addressing blocks on its model of the SSD. These can map to different physical blocks on the SSD. You don't specify which you are talking about at any given time.
Here's more information about what TRIM does:
You keep on mistaking your misunderstanding of what I'm saying for mine of TRIM. I understand what TRIM does.
Once the disk is full, "dirty" blocks have to be re-used.
So, all this time, you were imagining a full disk? Savvy SSD users leave 20% of so space so that wear leveling works better.
So, the OSX "solution" is a temporary fix.
For me, it lasted exactly as long as it had to.
However I'm pretty sure SSD write leveling behavior is standard across all other operating systems.
SSD write leveling isn't implemented by the OS. (Take some of your own medicine.) If, however, the OS prefers to "dirty" blocks and doesn't have TRIM, you more quickly get to the point where there are very few blocks the SSD can use for wear leveling.
I don't know why we keep returning to wear-leveling as a priority.
If SSD hardware life-cycle is so short that apex capacity isn't reached, garbage collection isn't required to maintain performance, and cell degradation is irrelevant.
I expect to use a storage medium at advertised capacity, at the advertised speed, for the life of the device. With TRIM support this is possible, no compromise necessary.
But the 2010 MBAs aren't using their flash storage through a SATA interface - they're directly mounted on the motherboard, probably exposed as a pure PCIe device. TRIM is irrelevant for them.
UPDATE:
BAH! Wrong. The MBA uses a Toshiba t6ug1xbg controller, which seems to provide a SATA interface. So it is an issue.
I'll agree that's been annoying. However, I've been happily running OS X with a Crucial RealSSD 300 on an original unibody Macbook since last December. Everything still seems zippy and instant. I'll let everyone know if Lion seems to make things faster. (More like prevents things from slowing down.)
I hope Apple adds a "secure erase" option that just overwrites files with 1's exactly one time. From what I've read, this is plenty secure for most people, and some SSDs can use this as a signal that a block is no longer in use. (My drive doesn't need this, but some people with older SSD would benefit from this.)
A good SSD will still seem much faster than a magnetic disk even without support for TRIM. TRIM just ensures that performance is as high as it should be throughout the life of the drive, and also that wear leveling reaches its full potential. On consumer MLC drives, especially those that are filled closer to their capacity, the use of TRIM can significantly affect performance and drive longevity.
From what I understand OS X does as much as it can to reuse whatever blocks it's already used. The SSD can present whatever physical locations it wants to OS X, so there's no direct control, but this policy preserves as many "unused" blocks as possible, which tends to be as friendly as possible to garbage collection and wear leveling. I am certainly not an expert, however.
You can set it to write all 0's once. You can't set it to write all 1's just once. There's another utility on OS X that will write 1's, 0's, then 1's. But using 3 writes means a considerable inflation in the number of dirtied physical blocks in the SSD.
How is it possible to replace TRIM at the hardware level? I wasn't aware there was any way for the drive to know what files the filesystem considers deleted. Unless the hardware module somehow detects what file system you're using...
Hardware GC is useful and decreases write-amplification problems, but it doesn't remove the need for TRIM (which affects wear leveling and physical fragmentation).
Hmm, typical Apple - we will support only what we ship. But it should be easy to enable for 3rd party drives - probably there is a plist somewhere that maintains a list of supported drives that can be hacked or worst case a kext needs to be hacked.
Yes typical Apple, they view their products as appliances. As Steve Jobs said in 2006 or 2007[1]: "We're getting to the point where everything is a computer in a different form factor. So... So what? Right, so what if it's built with a computer inside it. It doesn't matter. It's "what is it?" How do you use it? You know, how does the consumer approach it? And so who cares what's inside it anymore."
Of course we still see them as computers because we're geeks, but for most people they simply are appliances. If things break they're not going to open up the machine and take a look, just like their TV, washing machine, etc.
Whether or not you feel that computers should be appliances, Apple has always had this view of their products for better and for worse.
The Mac Pro is an appliance? Apple sells Graphics Cards, RAID Cards and stuff as add-ons to the Mac Pro. Mac Pros also can use SSDs and not many are going to be bought from Apple or packaged inside when it is bought.
It could be that support is coming. Or it could be that some SSD devices have buggy TRIM, or TRIM that works in different ways. Too early to say, but I'll wait for SSD expert comment on this matter.
However, I would be disappointed if it's not in by the release of 10.7.1.
Nit: the Apple ][ could be used as an appliance, more so than its 1977 competitors, but it was the opposite of a closed system. s/Apple/post-Wozniak Apple/
It's also just a lot easier for them to only support their own hardware configurations. Not having to adapt drivers for and test n-thousand configurations per component makes it faster, cheaper and easier for them to roll out support for new tech.
danudey left a helpful link to a comment I made recently about TRIM support in Lion. Apparently, 10.6 is doing some good SSD maintenance even without TRIM support, and SSDs do not experience the same performance drops as they would on a Windows machine without TRIM support, but it is not clear why this is the case.
Does that apply to all SSDs? From what I gather TRIM is just a spec for formalized OS-level garbage collection hooks. Some disks (like Apple-installed Samsungs) do GC at the disk-level.
My Sandforce (Vertex 2) has disk-level GC (as well as TRIM), and sometimes will block for a long period on writes now on OSX... I haven't tried it on a different OS yet.
To someone who bought a 2010 MBA in October and doesn't get an OS that supports TRIM until this summer, what's going to be the impact on the useful life of the SSD?
Apparently the SSD in the MBA uses the same Toshiba controller as this Kingston drive. It doesn't seem to need TRIM but takes care of garbage collection by itself.
None, I'd say. I've been running an older X25-m generation on a Win2K box for 14 months now. No TRIM in firmware, no TRIM in W2K. Disk has been filled and cleaned out numerous times since I bought it and it still performs adequately. I'd be surprised if your SSD would suffer from the few months until you get TRIM in 10.7.
On the other side of things, I've owned 3 X25-M's. A first gen that died in 9 months, a second gen (RMA replacement) that just started acting weird and corrupting things last month (was about 15 months old and was in a RAID 0 array with another X25M but I undid the array and began using the better of the two X25M's). Needless to say I use Dropbox, Time Machine and Carbon Copy Cloner very often.
