Software-defined flash provides a way to unleash the full performance of solid state drives (SSDs), while cutting the cost per megabyte of flash storage substantially.
This price and performance double whammy has already been achieved in the confines of data centers operated by Baidu, the Chinese web services giant. Technology developed in web-scale data centers in the cloud invariably trickles down to enterprise data centers, so it's a good bet that software-defined flash will be available to medium and large businesses within the next few years.
Before we take a closer look at software-defined flash, let's examine the problem with SSD storage. Although it offers a significant performance benefit over hard disk drives, it's relatively expensive. And a significant part of the cost of SSDs comes down to the fact that they are not designed to work at maximum efficiency, explains Jim Handy, a solid state storage expert and semiconductor analyst at Objective Analysis. "SSDs are not optimized for storage — they are designed to look as much like hard disk storage as possible, and that means that there are processes going on to hide the nature of SSD storage from the software that uses it," he says.
The reason for that is that most software — especially legacy applications and operating systems — has been designed to work with spinning disks. It's what applications expect, so SSDs have to emulate hard disks. In very basic terms, most software talks in the language of hard disk drive storage, and SSDs are expected to translate that language in to SSD language for themselves.
"The difficulty with legacy software is that it would take phenomenal efforts to upgrade it to take (full) advantage of flash," says Handy, "so the approach has been to leave it well alone and try to use something that looks like a very fast hard drive."
That means that while the flash controllers in SSDs are busy writing and reading data, they are also managing all the things that an application or operating systems doesn't bother with.
What sorts of things? Things like wear leveling — ensuring that the cells of flash memory are all used equally so that some cells don't get over used and burned out; and garbage collection — moving pages of valid data to new blocks while leaving invalid data so that the entire original block containing only invalid data can be erased and freed for reuse. (That's necessary because although SSDs can write at a page level, they can only erase an entire block of multiple pages. So to delete a page of invalid data, the SSD needs to delete the entire block that contains that page.)
Garbage collection is connected to something else that's necessary in an SSD: overprovisioning. Essentially an SSD with a given physical capacity has a lower usable capacity. (A typical 128GB consumer SSD may be offer 120GB of usable capacity (7% overprovisioning) while a 128GB enterprise SSD may be 28% overprovisioned, offering 100GB of usable space.)
The difference between physical and usable capacity is set aside as an area of empty blocks. These empty blocks can be used by the SSD's controller to store pages of data which have been moved from other blocks that also contain invalid pages of data so that those invalid pages can be deleted. Overprovisioning also gives the controller more flexibility when it comes to wear levelling.
So the question is this: What if SSDs could be made speedier by taking out those functions of the controller that could be better performed by a host server (with a reconfigured operating system or application or both)?
Baidu's software-defined flash system involves host software modification, but also modification to the SSDs themselves by reprogramming their field-programmable gate array(FPGA) -based controllers, according to a paper published by Baidu engineers and a researcher from Peking University and Wayne State University. This provides an interface so that the software can more directly access the SSD's internal operations and interact with them in a way more suited to their performance characteristics.
What Baidu did was remove the DRAM buffer in its SSDs as well as removing from the controller the logic for garbage collection, static wear levelling and inter-chip parity coding. These SSD housekeeping functions were instead made the responsibility of the host software. It then exposed all 44 internal NAND channels to the system software.