Why SSDs Care About What You Write: Fragmentation & Write Combining

PC Perspective's Allyn Malventano is a smart dude, just read one of his articles to figure that out. He pieced together a big aspect of how the X25-M worked on his own, a major key to how to improve SSD performance.

You'll remember from the Anthology that SSDs get their high performance by being able to write to multiple flash die across multiple channels in parallel. This works very well for very large files since you can easily split the reads and writes across multiple die/channels.

Here we go to write a 128KB file, it's split up and written across multiple channels in our tiny mock SSD:

When we go to read the file, it's read across multiple channels and performance is once again, excellent.

Remember what we talked about before however: small file random read/write performance is actually what ends up being slowest on hard drives. It's what often happens on a PC and thus we run into a problem when performing such an IO. Here we go to write a 4KB file. The smallest size we can write is 4KB and thus it's not split up at all, it can only be written to a single channel:

As Alyn discovered, Intel and other manufacturers get around this issue by combining small writes into larger groups. Random writes rarely happen in a separated manner, they come in bursts with many at a time. A write combining controller will take a group of 4KB writes, arrange them in parallel, and then write them together at the same time.

This does wonders for improving random small file write performance, as everything completes as fast as a larger sequential write would. What it hurts is what happens when you overwrite data.

In the first example where we wrote a 128KB file, look what happens if we delete the file:

Entire blocks are invalidated. Every single LBA in these blocks will come back invalid and can quickly be cleaned.

Look at what happens in the second example. These 4KB fragments are unrelated, so when one is overwritten, the rest aren't. A few deletes and now we're left with this sort of a situation:

Ugh. These fragmented blocks are a pain to deal with. Try to write to it now and you have to do a read-modify-write. Without TRIM support, nearly every write to these blocks will require a read-modify-write and send write amplification through the roof. This is the downside of write combining.

Intel's controller does its best to recover from these situations. That's why its used random write performance is still very good. Samsung's controller isn't very good at recovering from these situations.

Now you can see why performing a sequential write over the span of the drive fixes a fragmented drive. It turns the overly fragmented case into one that's easy to deal with, hooray. You can also see why SSD degradation happens over time. You don't spend all day writing large sequential files to your disk. Instead you write a combination of random and sequential, large and small files to the disk.

The Cleaning Lady and Write Amplification A Wear Leveling Refresher: How Long Will My SSD Last?
Comments Locked

295 Comments

View All Comments

  • Anand Lal Shimpi - Monday, August 31, 2009 - link

    The tables the drive needs to operate are also stored in a small amount of flash on the drive. The start of the circular logic happens in firmware which points to the initial flash locations, which then tells the controller how to map LBAs to flash pages.

    Take care,
    Anand
  • Bakkone - Monday, August 31, 2009 - link

    Any gossip about the new SATA?
  • Zaitsev - Monday, August 31, 2009 - link

    Thanks for the great article, Anand! It's been quite entertaining thus far.
  • cosmotic - Monday, August 31, 2009 - link

    The page about sizes (GB, GiB, spare areas, etc) is very confusing. It sounds very much like you are confusing the 'missing' space when converting from GB to GiB with the space the drive is using for its spare area.

    Is it the case that the drive has 80GiB internally, uses 5.5GiB for spare, and reports it's size as 80GB to the OS leaving the OS to say 74.5GiB as usable?
  • Anand Lal Shimpi - Monday, August 31, 2009 - link

    I tried to keep it simply by not introducing the Gibibyte but I see that I failed there :)

    You are correct, the drive has 80GiB internally, uses 5.5GiB for spare and reports that it has 156,301,488 sectors (or 74.5GiB) of user addressable space.

    Take care,
    Anand
  • sprockkets - Tuesday, September 1, 2009 - link

    Weird. So what you are saying is, the drive has 80Gib capacity, but then reports it has 80GB to the OS, advertised as having an 80GB capacity, which the OS then says the capacity is 74.5GiB?
  • sprockkets - Tuesday, September 1, 2009 - link

    As a quick followup, this whole SI vs binary thing needs to be clarified using the proper terms, as people like Microsoft and others have been saying GB when it really is GiB (or was the GiB term invented later?)

    For those who want a quick way to convert:

    http://converter.50webs.com">http://converter.50webs.com
  • ilkhan - Monday, August 31, 2009 - link

    so they are artifically bringing the capacity down, because the drive has the full advertised capacity and is getting the "normal" real capacity. :argh:
  • Vozer - Monday, August 31, 2009 - link

    I tried looking for the answer, but haven't found it anywhere so here it is: There are 10 flash memory blocks on both Intel 160GB and 80GB X25-M G2, right? (and 20 blocks with the G1).

    So, is the 80GB version actually a 160GB with some bad blocks or do they actually produce two different kind of flash memory block to use on their drives?
  • Anand Lal Shimpi - Monday, August 31, 2009 - link

    While I haven't cracked open the 80GB G2 I have here, I don't believe the drives are binned for capacity. The 80GB model should have 10 x 8GB NAND flash devices on it, while the 160GB model should have 10 x 16GB NAND flash devices.

    Take care,
    Ananad

Log in

Don't have an account? Sign up now