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.

The Blind SSD Free Space to the Rescue
POST A COMMENT

236 Comments

View All Comments

  • Hrel - Thursday, April 09, 2009 - link

    although, I have some issues which I have put in an e-mail sent to Anand; can't wait for you response. Reply
  • Hrel - Thursday, April 09, 2009 - link

    Instead of making me dinner can you send me that test system instead??? Please!!! Reply
  • Hrel - Thursday, April 09, 2009 - link

    I was wondering what controller the OCZ solid Series is based on??? Will I experience hiccups with that drive or not? Is the point of my question. Reply
  • sfisher64 - Wednesday, April 08, 2009 - link

    I just purchased a Dell Latitude E6400 with a 64GB Ultra Performance Solid State Drive. Does anyone know what type of drive this is, and where it fits in the spectrum described in this article? Reply
  • Baffo - Saturday, April 11, 2009 - link

    The Dells use the Samsung drives (you should see this on the bottom if you pull it out). However, as much as I wish this was one of the newer controllers (I have a few of these at work as well), the testing cycles demanded by Dell probably mean these are the older controllers. Reply
  • marraco - Tuesday, April 07, 2009 - link

    This article is popular :) Reply
  • BLHealthy4life - Monday, April 06, 2009 - link

    Intel 9.1.1.1010 (Intel) Where are these drivers? I can only find version 1007 and not 1010....

    Thanks
    Reply
  • BLHealthy4life - Sunday, April 12, 2009 - link

    found it....

    Intel obviously keeps the X58 chipset drivers current for their own boards, just not other mfgs boards....

    They installed fine on my R2E..

    BL
    Reply
  • irondukes - Friday, April 03, 2009 - link

    Hi-- Do SLCs suffer from performance degradation, or are the controllers pretty agressive at erasing the data since they have far longer read-write cycles? Please help! Deciding between an X25E and X25M Reply
  • mdavies - Friday, April 03, 2009 - link

    I'm reading this about a day late - got my Patriot PE256GS25SSDR 2.5" 256GB yesterday since I'm bad about destroying hard drives. this drive, in a word, was excruciating. I'll be replacing it with one of your recommended drives today.

    Thanks
    Reply

Log in

Don't have an account? Sign up now