Not only that. I've been a Mac user for almost 10 years now but I'm waiting for them to add TRIM support to OS X before taking the SSD plunge. Everybody using an SSD on OS X should understand that its performance will degrade more quickly than on another modern OS. It's quite disappointing to me.
To clarify: There are two writing speeds of an SSD, one when the block is empty and one when the block already has data, the latter is slower and TRIM support from the OS will allow the SSD to know about “dead data” so that it can reorganize data to optimize free blocks.
I am using the first generation Intel SSD which doesn’t actually support such reorganization and isn’t noticeable affected by “being full” (as opposed to writing to the factory default empty state).
I am also using Crucial SSD (with OS X) and that as well is magnitudes faster than my previous mechanical disk.
So all in all, this degraded performance is blown a bit out of proportion and you are doing yourself a great disservice by holding out for TRIM support — to echo others: SSD was the best upgrade I added to my system.
Edit: I am btw using SSDs with a desktop system. So I compare them with my previous 7200 RPM drives. For a laptop there is absolutely no doubt that you should go with an SSD (if you can afford it), TRIM support or not. For a desktop, I would still highly recommend it.
I totally agree if it's a choice between somewhat decent SSD (e.g., I'd probably avoid the Samsungs that Apple actually offers) or hard disk, go for SSD. I'm just disappointed that Apple hasn't yet enabled TRIM support. They apparently laid the groundwork for it in the kernel but haven't actually finished off the work. Every time they roll out new models, I check to see if they've actually enabled TRIM support in a point update of OS X but they haven't. They'll eventually have to as it's being rolled into the ATA specification.
Just had to look that up myself. Shocking that OS X doesn't support it natively, although the article suggests there may be utilities that can replace that functionality.
Deleted my previous ignorant comment - I had it backwards.
The idea behind TRIM is so the OS can tell the drive when a block is free, so the SSD can pro-actively erase it, which is something that otherwise slows down the write cycle if you are writing to a block that wasn't already clean. That's not something you can just magic into a drive.....
Unfortunately while there are strategies to mitigate the problem in hardware, proper TRIM support is still best. You might be getting confused by the TRIM enabled firmware that was released in December '09 for that SSD? It just means that the Intel drive will obey TRIM commands from the OS. But if the OS doesn't send any commands, which OS X won't, then you're not taking advantage of TRIM. For what it's worth, if you were going to choose a drive that would degrade the least in performance without the use of TRIM, you probably chose best with the Intel X-25M. But it would still perform better over time in Linux or Windows 7.
The drive does not know when data stored on the drive is “deleted”. This is what TRIM is for, i.e. when you delete a file you just unlink the inode. You need to tell the drive that the blocks that the file occupied are no longer needed, so the disk can ignore that data when reorganizing or later rewriting part of the block.
I don't know about that. I've had this SSD-based 15" MBP since last fall, using it full-time, and it certainly hasn't fallen off any performance cliffs.
So maybe this is more of a theoretical problem than a practical one?
It depends on your usage patterns. Performance begins to degrade as soon as you've written an amount of data roughly equal to the SSD's total capacity. If you're not writing much data to the drive on a regular basis, then it'll take a while to hit that wall. But once you do, it's a significant drop in performance for most SSDs. And at that point, the only "fix" is to format the drive.
as soon as you've written an amount of data roughly equal to the SSD's total capacity
After eight months of heavy daily use, in which I'm quite certain I've achieved more than 256GB of total writes, I've seen... no change in performance. Still zippy and happy and writing just fine.
Time for misguided hype based on anandtech's articles to go away now.
As I said, it depends on usage patterns. (I also oversimplified the problem description. My apologies.)
If you're only using a small fraction of the total capacity, chances are you won't see much performance degradation for a long while no matter how much you write to the drive because of minimal fragmentation at the block level. But given enough time, you'd still hit that wall at some point.
But if you're using a large fraction of the total capacity, then you're going to have much more fragmentation, which means pages that can't be erased without having to rewrite significant numbers of blocks in those pages. Those ephemeral writes will start taking a real performance hit.
Many newer SSDs now include logic in their controllers to help mitigate this problem, with varying degrees of success. But full TRIM support on the drive and in the OS make a significantly larger difference than anything done by the drive alone. (Even with TRIM, though, the problem doesn't go away completely.)
And this isn't just some kind of spin from Anandtech--TRIM exists for a reason. It's a well-tested property of MLC SSDs. The combination of wear leveling and write combining can cause serious performance issues without TRIM. This article describes it pretty well: http://www.pcper.com/article.php?aid=669&type=expert&...
If you're only using a small fraction of the total capacity
At any given moment I'm using about half the total capacity. I'm not regularly doing huge writes, but as someone who works with a ton of remote and local repositories, pulling/merging/etc. many times a day, I do end up doing a huge number of small writes nearly continuously; I'd be surprised if I haven't hit every bit of that drive at least once by now. And I haven't seen any dramatic, or even noticeable, degradation.
And this isn't just some kind of spin from Anandtech
It's more that a bunch of people skimmed the anandtech articles, then started spouting a lot of gratuitous "X25-M is the One True SSD, everything else is shit" hype, which later morphed into "never use an SSD in an OS that doesn't do TRIM" hype. Of course, the hype doesn't quite match the reality...
Well, it's not so much which parts of the SSD have been touched, it's more about which pages have currently-in-use blocks stored in them. If you're using half the capacity of the drive, then it's likely you have a considerable number of empty (or at least erasable-without-needing-extra-writes) pages--especially if your drive's controller does some basic defragmentation.
And no, SSDs aren't worthless without TRIM. But if you're likely to use the majority of the storage space on the drive and do a lot of writes besides, it could be the difference between "fast" and "really damn fast." Either way it'll still beat the pants off most rotational disk drives.
I think the takeaway, though, is that if you've spent potentially-obscene amounts of money on an SSD, wouldn't you prefer that your OS take full advantage of its capabilities to consistently deliver top performance?
(And no, that's not a dig at OS X. I'd recommend that Windows XP users upgrade to Win7 if they're considering upgrading to an SSD simply for the TRIM support. It can make that much of a difference depending on the user.)
As another datapoint, I had a laptop with a first-gen SSD and no TRIM or GC support. The performance hit a literal cliff; writes were fast one day, and the next day they were literally 300KiB/s. Download speeds were limited by disk write bandwidth, not network bandwidth! New SSD, writes are back up to 50MiB/s.
(The divide might not be at the capacity of the disk; this was a 16GiB SSD with probably 20x that in writes.)
Well, after 6-7 months of heavy use on my MBP (easily past 128GB worth of writing, many times), Xbench says I'm getting 100MB/sec for just about all disk activity with 256K blocks.
