What’s In A Name(space)? Optimizing SSD Controller Performance And Verification

Solid state drives (SSDs) have come to the forefront as a promising solution for today and tomorrow’s immense data transfer and storage demands. And SSDs themselves are constantly evolving with upgrades of their critical components to provide higher access speeds. One such component for the NVMe specification is created by the division of non-volatile memory (NVM) into what are commonly known as namespaces.

Namespaces are perceived as formatted logical blocks that kick-start block storage in SSDs. Each block in a typical flash chip consists of a large number of pages. Data is read and programmed into flash chips in the order of pages but erased in the order of blocks. To reprogram a page, the entire block must first be erased. An SSD supports a limited number of these program and erase cycles before its lifetime expires. To extend the lifespan of an SSD, a flash translation layer (FTL) performs routine tasks, such as garbage collection, to free up memory space for future programming, and wear levelling, to evenly spread work across all the blocks so that all blocks wear out at the same time.

Although this type of namespace provides a dependable solution, it gives a substandard performance for a variety of reasons. Since every digital device has a storage system in it, the focus should be to devise a cost-effective alternative which is proficient and reliable. With the intention to attack the shortcomings of traditional block storage, the NVMe 2.0 specification has introduced two alternatives for optimizing performance and meeting industry requirements: zoned namespace (ZNS) and key value (KV) namespace.

Zoned namespaces

ZNS SSDs offer optimized performance for sequential write workloads. These are particularly beneficial for hyper-scale organizations, enterprises, and large data storage centers.

Zoned namespaces are categorized into zones which consist of a sequentially laid out, non-overlapping range of logical blocks. As per the NVMe 2.0 specification, these zones are “sequential write required,” which means that data must be sequentially written into these zones. In order to rewrite data in a zone, it must be reset. The host is required to maintain a write pointer for each zone so that data is sequentially placed. This data placement is done as a collaborative effort between the host and the SSD.

Fig. 1: Zoned namespace layout.

Each zone has attributes associated with it, such as zone size, zone capacity, zone starting logical block, zone state, and resources. The NVMe ZNS command set specification gives an exhaustive methodology to create host-controller interfaces for ZNS SSDs.

How the categorization of zones is done is entirely up to the host. For instance, if zones are categorized on the basis of the lifetime of data, then data with a higher life expectancy will be put together in one zone and data with a lower life expectancy will be put in another zone. In the case of random write workload, when such zones are sequentially written, then the excessive garbage collection to free space for future writes is avoided. Since garbage collection has a direct impact on the performance of an SSD, mitigating it works in the favor of ZNS SSDs.

Fig. 2: Data placement in traditional block storage SSD vs zoned namespace SSD.

Key value namespaces

KV SSDs are particularly suitable for unstructured data, like music, photos, and zip files. They can offer benefits to big data processing and can replace object storage systems.

Key value namespaces are represented as a collection of variable-sized key-value pairs, instead of traditional logical blocks. These key-value pairs consist of a key which has a maximum size of 16 bytes and a value which is the actual data to be stored in the namespace. Keys are used in order to access data in KV SSDs, instead of the logical block addresses in traditional block storage. This new mapping scheme eliminates the translation layers necessary to achieve mapping with physical block addresses.

Fig. 3: Key-value namespace layout.

In key-value storage, data is not fragmented into blocks but is stored as a continuous collection of bytes mapped with a unique key. When a key is deleted, data associated with it gets erased and the entire continuous physical space gets freed for future use. This relieves the negative impact of garbage collection on the performance of an SSD.

Fig. 4: Data placement in traditional block storage SSD vs key-value SSD.

Verification of SSD controllers

Unfortunately, it is not that easy to plug-in to either ZNS SSDs or KV SSDs after unplugging from traditional block storage SSDs. In order to gain the performance benefits offered by these SSDs, it is required to modify the ecosystem (operating system, applications, and file systems) to support the ZNS and KV semantics. For ZNS SSDs, the host has to take care of the placement and management of data in different zones based on the parameter favorable to the host.

NVMe Questa Verification IP (QVIP) provides verification for SSD controllers that support a single type of namespace: either traditional block storage namespaces in conventional SSDs, zoned namespaces in ZNS SSDs, or key-value namespaces in KV SSDs. Additionally, NVMe QVIP can provide verification for SSDs which support multiple types of namespaces, as per the NVMe 2.0 specification, where the idea of an SSD supporting more than one type of namespace is plausible.

NVMe QVIP complies with the NVMe 2.0 specification and NVMe command set specifications for NVM, ZNS, and KV command sets. It provides a built-in library of sequences for I/O commands as well as admin commands that can be used to generate stimulus for simulation tests. Support of loading and dumping data structures is available through backdoor processes during bring up. Further, it provides a means for thorough testing using exhaustive assertions.

I/O commands that are supported over all command sets, like flush and reservation commands, are also supported by NVMe QVIP. Once a stimulus is generated, it can be run on different namespaces.

Please refer to the full whitepaper Unblocking the Full Potential of SSDs Using Zoned and Key Value Namespaces to learn more about the performance characteristics that enable the newly introduced ZNS SSDs and KV namespace SSDs to outperform traditional block-storage based SSDs. The paper also details the verification support that NVMe QVIP provides for verification of these SSDs and highlights the performance statistics measured by NVMe QVIP that are useful in analyzing SSD efficiency.