The SSD Anthology: Understanding SSDs and New Drives from OCZ
by Anand Lal Shimpi on March 18, 2009 12:00 AM EST- Posted in
- Storage
Putting Theory to Practice: Understanding the SSD Performance Degradation Problem
Let’s look at the problem in the real world. You, me and our best friend have decided to start making SSDs. We buy up some NAND-flash and build a controller. The table below summarizes our drive’s characteristics:
| Our Hypothetical SSD | |
| Page Size | 4KB |
| Block Size | 5 Pages (20KB) |
| Drive Size | 1 Block (20KB |
| Read Speed | 2 KB/s |
| Write Speed | 1 KB/s |
Through impressive marketing and your incredibly good looks we sell a drive. Our customer first goes to save a 4KB text file to his brand new SSD. The request comes down to our controller, which finds that all pages are empty, and allocates the first page to this text file.
Our SSD. The yellow boxes are empty pages
The user then goes and saves an 8KB JPEG. The request, once again, comes down to our controller, and fills the next two pages with the image.
The picture is 8KB and thus occupies two pages, which are thankfully empty
The OS reports that 60% of our drive is now full, which it is. Three of the five open pages are occupied with data and the remaining two pages are empty.
Now let’s say that the user goes back and deletes that original text file. This request doesn’t ever reach our controller, as far as our controller is concerned we’ve got three valid and two empty pages.
For our final write, the user wants to save a 12KB JPEG, that requires three 4KB pages to store. The OS knows that the first LBA, the one allocated to the 4KB text file, can be overwritten; so it tells our controller to overwrite that LBA as well as store the last 8KB of the image in our last available LBAs.
Now we have a problem once these requests get to our SSD controller. We’ve got three pages worth of write requests incoming, but only two pages free. Remember that the OS knows we have 12KB free, but on the drive only 8KB is actually free, 4KB is in use by an invalid page. We need to erase that page in order to complete the write request.
Uhoh, problem. We don't have enough empty pages.
Remember back to Flash 101, even though we have to erase just one page we can’t; you can’t erase pages, only blocks. We have to erase all of our data just to get rid of the invalid page, then write it all back again.
To do so we first read the entire block back into memory somewhere; if we’ve got a good controller we’ll just read it into an on-die cache (steps 1 and 2 below), if not hopefully there’s some off-die memory we can use as a scratch pad. With the block read, we can modify it, remove the invalid page and replace it with good data (steps 3 and 4). But we’ve only done that in memory somewhere, now we need to write it to flash. Since we’ve got all of our data in memory, we can erase the entire block in flash and write the new block (step 5).
Now let’s think about what’s just happened. As far as the OS is concerned we needed to write 12KB of data and it got written. Our SSD controller knows what really transpired however. In order to write that 12KB of data we had to first read 12KB then write an entire block, or 20KB.
Our SSD is quite slow, it can only write at 1KB/s and read at 2KB/s. Writing 12KB should have taken 12 seconds but since we had to read 12KB and then write 20KB the whole operation now took 26 seconds.
To the end user it would look like our write speed dropped from 1KB/s to 0.46KB/s, since it took us 26 seconds to write 12KB.
Are things starting to make sense now? This is why the Intel X25-M and other SSDs get slower the more you use them, and it’s also why the write speeds drop the most while the read speeds stay about the same. When writing to an empty page the SSD can write very quickly, but when writing to a page that already has data in it there’s additional overhead that must be dealt with thus reducing the write speeds.
Facebook
Twitter
RSS
250 Comments
View All Comments
siberx - Thursday, March 19, 2009 - link
This is, very likely, the best article I have ever read, period. Online, in magazines, about any subject... this was an absolutely fantastic read. Suddenly, all smoke surrounding SSDs has cleared and the truth shines through in editorial brilliance. It's great to see that at least some computer news sites out there can still cut through the crap and get to the heart of the issue. My already high opinion of AnandTech has risen even further.Thank you for taking the immense time it must have taken to compile and assemble all this information - this article is now a must-read for *anybody* considering purchasing an SSD, and it's just about all the background you could need in one place.
In addition to all the extremely useful general SSD information contained within, the detailing of the issues with the JMicron controllers as well as OCZ's efforts to address the concerns to produce the best product possible (despite the reduced marketability to the uninformed) is reassuring and comforting in a world where tech companies seem more concerned with how much they can deceive their customers instead of producing quality products.
In short, the article is a win on all fronts, thank you greatly for posting it. When I purchase my first SSD (which I'm considering doing reasonably soon) this article, its information and suggestions, and OCZs actions to resolve the issues with its drives will definitely be at the forefront of my mind.
jkua - Thursday, March 19, 2009 - link
I have to say, I really appreciate the effort and throughness with which you have covered the state of the SSD market today. As an engineer and scientist, I applaud your methods in tracking down and reporting the major issues with SSDs. As a consumer, I really appreciate the timeliness of this article as I was just thinking of putting an SSD in a netbook for a robotics application where mechanical drives are not ideal.Cheers!
jkua - Thursday, March 19, 2009 - link
That said, one thing I would have like to have seen is some numbers on power consumption for these drives compared to average mechanical desktop and laptop drives.aamsel - Thursday, March 19, 2009 - link
Anyone have a link to the Intel HDD ERASE program that Anand referred to?HolyFire - Thursday, March 19, 2009 - link
http://www.ultimatebootcd.com/download.html">http://www.ultimatebootcd.com/download.html (includes HDD erase 3.1)http://cmrr.ucsd.edu/people/Hughes/SecureErase.sht...">http://cmrr.ucsd.edu/people/Hughes/SecureErase.sht... (version 4.0)
AnnonymousCoward - Thursday, March 19, 2009 - link
AWESOME ARTICLE.The huge difference in read/write flash performance looks a lot like this article: http://www.anandtech.com/memory/showdoc.aspx?i=257...">http://www.anandtech.com/memory/showdoc.aspx?i=257...
wind glider - Thursday, March 19, 2009 - link
Thanks for the orgasmic review.wicko - Wednesday, March 18, 2009 - link
Had a really good read here, thanks for the history and info, Anand. The only thing I don't understand is what the importance of random write is? What kind of task would benefit from high random write speeds (maybe copying many files at once)? I'm tempted to pick up a vertex drive but it depends on whether or not random write will be important for me. But the price... whoa, pretty damn expensive here in Canada.. http://www.ncix.com/products/index.php?sku=36023&a...">http://www.ncix.com/products/index.php?...X120G&am... - $625 for a 120GB!!! I kind of want 2, for RAID0, I have a lot of games installed (steam folder alone is 100GB lol). Might even have to raid 3 of em.. but not for $1800 lol.strikeback03 - Thursday, March 19, 2009 - link
As mentioned in the article, the OS in general makes lots of random writes. Send an IM, it writes to a log. Load a website, it caches some images.AnnonymousCoward - Thursday, March 19, 2009 - link
>I'm tempted to pick up a vertex drive but it depends on>whether or not random write will be important for me.
Keep in mind, its random write is twice as fast as mechanical HDs.
>But the price...
It's only $110USD/32GB.