Slashdot Mirror
The Curious Case of SSD Performance In OS X
mr_sifter writes "As we've seen from previous coverage, TRIM support is vital to help SSDs maintain performance over extended periods of time — while Microsoft and the SSD manufacturers have publicized its inclusion in Windows 7, Apple has been silent on whether OS X will support it. bit-tech decided to see how SSD performance in OS X is affected by extended use — and the results, at least with the Macbook Air, are startling. The drive doesn't seem to suffer very much at all, even after huge amounts of data have been written to it."
I've got a Vertex 60 in a While unibody macbook and it works fine, boot is 7-9 seconds, apps load almost instantly even if i start 10 at the same time.
I know TRIM doesn't work yet in OS X but the drive seems to take care of itself just fine.
It depends a lot on how the drive works.
Intel drives actually use the whole drive for scratch space. Until a sector is written to. Then without TRIM it only has its tiny bit of extra scratch space to work with. That's why intel drives degrade so badly without TRIM.
Indilinx Barefoot controllers on the other hand ONLY use their scratch space, they never use the normal writing space of the drive as scratch space.
See here.
http://www.anandtech.com/show/2829/9
While it does show the synthetic tests degrading with lack of trim, even more than the intel drives, the real world use tests show they suffer almost 0% loss in performance.
Depending on which controller the drive is using, TRIM could make almost no difference or a world of difference.
Anand explains it best:
"Only the Indilinx drives lose an appreciable amount of performance in the sequential write test, but they are the only drives to not lose any performance in the more real-world PCMark Vantage HDD suite. Although not displayed here, the overall PCMark Vantage score takes an even smaller hit on Indilinx drives. This could mean that in the real world, Indilinx drives stand to gain the least from TRIM support. This is possibly due to Indilinx using a largely static LBA mapping scheme; the only spare area is then the 6.25% outside of user space regardless of how used the drive is."
It's easier to fight for one's principles than to live up to them.
The article writers made 2 major mistakes that cause their results to be meaningless.
1. They didn't secure erase the drive, which is what actually puts a drive back into a virgin state. They instead wrote zeroes to every sector, which means that the drive controller probably still thinks those zeroed out sectors are still in use.
2. The Samsung drive controller has a form of self cleanup that greatly reduces the need for TRIM.
3. Regardless, the SSD they used was slow as a dog and barely worth using over a HDD.
if you read it you'll either get random data, or zeros (probably the later)
If you read a TRIMmed block directly, most drives will kick back zeroes. You can do this with hdparm -- particularly useful as a method to test if TRIM works (and it even uncovered a bug in ext4's TRIM implementation in data=writeback mode, where TRIM only works on metadata). Run hdparm -I on a SSD, and it'll actually say something along the lines of "Deterministic read ZEROs after TRIM" for most drives.
In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.
Very true. There are only two methods I know of to 'clean slate' a full drive -- either TRIM the entire thing (with a tool like hdparm -- this is tricky to get right) or run an ATA Secure Erase command. Most SSDs take the secure erase command and just blank every NAND chip they have (taking ~2 minutes compared to the multiple hours that rotational drives take for the Secure Erase command) -- I've done this on my X-25M and it works brilliantly.
Unless Apple's Disk Utility actually does a Secure Erase command (which is very unlikely), then their testing methodology is entirely flawed, and their 'resetting' of the drive instead made it behave as if it was entirely, completely, 100% filled to the brim.
Actually TRIM ensures there are free blocks of flash ready to be written quickly, otherwise they have to be erased first even if the OS thinks that particular logical address wasn't being used, which has a substantial performance penalty.
"If you put a good SSD (e.g. Intel) in your Mac the behavior will be completely different."
Completely different from what?
I have put an Intel SSD in a Mac, in fact 2 in a RAID 0 configuration, and it doesn't behave like you are insinuating it does.
The performance of the Samsung drives does suck but it isn't because they are "pre-degraded".
You both need to read up on TRIM (and I'll leave it at that)... http://en.wikipedia.org/wiki/TRIM
Yes, and as we know, solid state disks lose performance when files are fragmented, because, when the disk spins, err, i mean the electrons, the heat goes around, ah, fuck it.
Your reply was witty, but all of the EEs here on Slashdot will tell you that, for example, trying to write to random addresses in, for example, DDR2 memory when you could have written the same data to contiguous addresses, is a very bad idea. The only reason programmers don't feel this difference quite so much is that the cache hierarchy of the CPU is babying them.
An inaccurate pro-Mac story too, by the looks of it. For the Mac test, they didn't properly erase the SSD to its initial state - instead they used a tool that filled the disk with zeros, marking the entire drive as in-use. It's no surprise that they failed to see any performance degradation as the drive filled up: the performance was already maximally degraded from the start!