How to manage Open-Channel SSDs vs. self-managed SSDs
Open-Channel SSDs can be beneficial but only in the right uses. There are several key differences to analyze with their management as compared to self-managed SSDs.
Open-Channel SSDs move some SSD management from the SSD into the server. Moving wear management, garbage collection and scheduling can benefit the system if they are managed with an understanding of the application workload.
As a basis for this explainer, the following list compares key tasks performed by an SSD controller in a self-managed SSD with how they operate in an Open-Channel SSD.
Wear management
Flash bits wear out after they have undergone too many writes. A self-managed SSD, through data placement, moves those writes around to try to give all cells a similar number of writes. The data in a standard SSD is never in the location that the host requests. Instead, it is mapped to a location that the SSD controller determines. This mapping involves not only the flash visible to the host, but also the hidden overprovisioned flash.
An Open-Channel SSD moves the data placement task to the host, giving the host full visibility to the available flash, plus the overprovisioned flash. This is useful because, if the host understands that the application's write workload is low, it can reassign the overprovisioned flash, making some of it available to the application. The SSD looks bigger than a self-managed SSD that was made using the same amount of flash.
An Open-Channel SSD moves the data placement task to the host, giving the host full visibility to the available flash, plus the overprovisioned flash.
Conversely, if the application program presents an unusually high write load, the host can assign a larger share of the SSD's internal flash to overprovisioning. That reduces the amount of storage available to the application program in return for better performance and a longer lifetime.
The Open-Channel SSD also manages write coalescing, another wear management technique. Repeated writes to a single location, or writes to a series of adjacent locations, are buffered in RAM until enough data is available to fill a flash page. This process can turn many writes into a manageably small number. All the write buffering and coalescing are performed in a buffer in the server's main memory.
A self-managed SSD performs write coalescing in a write buffer that is either in the SSD controller chip's internal static RAM or in an external dynamic RAM chip, depending on the cost and performance tradeoff chosen by the controller's architect.
Garbage collection
Garbage collection is the process of freeing up blocks of NAND flash by moving valid pages from a number of partially used blocks into another block and then erasing the block those pages were taken from. This is how the SSD makes space available to new incoming data.
When garbage collection is under the control of the host in an Open-Channel SSD, application programs can advise the host of the times when it is more tolerable. At other times, garbage collection might present performance issues.
Garbage collection should perform in the background so as not to interfere too much with the SSD's intended operations. In a typical SSD, though, this process generally seems to get in the way of normal operation. The SSD has no understanding of the access patterns to expect from the host, so it must guess the best times to perform the process.
Scheduling
In an Open-Channel SSD, the application program can proactively tell the host-based scheduler when the workload will change, whether from a high-write to a high-read phase or from sequential to random. The program can also note when it plans to go quiet for a while, in which case it might be a good time for the SSD to get caught up with write buffer flushes and garbage collection.
In a self-managed SSD, the host runs application programs that issue commands. In the meantime, the SSD must find the time between these seemingly random host requests to perform garbage collection, write the coalescing buffer into the flash and erase unused blocks. This operation interferes with others going on in the same NAND flash chip. The management of these operations isn't at all synchronized to the host-based application program.
The self-managed SSD's solution to this problem is to try to second-guess the host's access patterns and to adopt a schedule to fit.
Applications must adapt to these SSDs
The only way to benefit from Open-Channel SSDs is to use applications that understand them and can communicate with the host-based SSD management software. It doesn't help to give the host control of the SSD if it's going to perform it as an independent process, unaware of the applications. This provides no advantage over a self-managed SSD. As a result, data centers that use off-the-shelf software can't take advantage, since few of these programs support the Open-Channel SSD architecture.
Commercial software tends to get written for the existing hardware installed base. The installed base doesn't usually convert to different hardware without a good reason. That reason doesn't exist without the software. It's a vicious circle.
It should come as no surprise that it's almost exclusively hyperscalers that use Open-Channel SSDs, since these organizations have total control of their application software and can modify it to manage the SSD. Hyperscale data centers see a benefit in rewriting their applications to take advantage of a new type of hardware if it can help to reduce costs. If admins can save $10 on each of 100,000 servers, then a $500 million software rewrite effort is money well spent.
This concept, which was originally used by Fusion-io in the early days of enterprise PCIe SSDs, fell into disuse but then reappeared at Baidu, a hyperscaler in China, some years later. Since then, other hyperscalers have adopted it in significant volumes.
Jim Handy is semiconductor and SSD analyst at Objective Analysis in Los Gatos, Calif.
