Answering Your Questions: “NVMe® 2.0 Specifications: Fast, Simple and Optimized for the Future of Storage” WebinarBlog
By Bill Martin, Samsung, Matias Bjørling, Western Digital, Nick Adams, Intel and Peter Onufryk, Intel
The recent “NVMe 2.0 Specifications: Fast, Simple and Optimized for the Future of Storage” webinar provided a comprehensive overview of the (NVM Express®) NVMe® 2.0 specifications refactoring effort, critical specification features, and new command sets such as Zoned Namespace (ZNS) and Key Value (KV). As contributors to the NVMe 2.0 specifications, we also explored why these changes were made, how they will affect the NVMe device environment and how the new features will impact NVMe SSD development and performance. If you missed the live webinar, the recording is available on YouTube and BrightTALK.
We received several questions during the Q&A portion of the webinar and have shared a recap of the questions and answers discussed during the webinar below.
Q: How many command sets did NVM Express support before the NVMe 2.0 specifications?
Although we had support for multiple command sets, the NVM command set was the only IO command set. The NVM command set is well known as the traditional block storage command set.
Q: How did you come up with specification partitioning that was used?
The specification partitioning was centered around how we align NVMe specifications with the architectural constructs that existed within NVM Express. We looked at what are the basic constructs necessary for any command set and for any transport; this became the NVMe Base Specification. There were different device formats that required different commands to access them; these became the command set specifications. There were multiple communication channels; these became the transport specifications. A device can implement a single command set and a single transport, so having these specifications separate made it transparent as to what a device implementing any specific command set(s) and any specific transport(s) was required to implement. Moving forward, we expect to add or modify command sets and transport specifications independently of the NVMe Base Specification. The NVMe Base Specification will apply to any command set and any transport specification.
Q: Does the Zoned Namespace (ZNS) command set eliminate the flash translation layer? Does the host have to manage the NAND directly?
An SSD that implements the ZNS Command Set is very similar to today’s conventional SSDs and implements a similar flash translation layer (FTL) that continues to manage the media within the SSD, such that NAND media specific behaviors continues to be managed internally. With ZNS SSDs, the only thing the host must think about is writing sequentially within the zone, the host should not manage the media liability in any other way than it already does with conventional drives.
Q: Can Zoned Namespace (ZNS) and Key Value (KV) features coexist for the same device?
The command sets are per namespace, meaning a given namespace can only support one command set at any given time. A single device may indeed support multiple command sets. A single device could have a namespace configured as a ZNS namespace and a separate namespace configured as a KV namespace. There are certain applications that have significant value in using both ZNS and KV on a single device.
Q: Is a single namespace formatted for a single specific command set?
That is correct, any namespace is formatted and used for a specific command set. A Namespace is formatted for a specific command set and then attached to controllers. If the controller is provisioned to support multiple command sets, you can interleave commands to the namespaces that support different command sets arbitrarily.
Q: What drove NVM Express to support Hard Disk Drives (HDDs)?
In the past, there were other storage technologies that storage arrays and infrastructure were built around. As SSD availability has grown, people are now building their infrastructure around NVMe technology first. There is a need to be able to plug hard drives into this infrastructure, and multiple companies asked for support for HDDs, which drove us to support them.
Q: For the Key Value command set, how do you expect SSDs to support byte granularity?
The expectation is that a device will allocate space on the granularity of the physical media, and if necessary, have unused bytes on the physical media. When the data is returned because it knows the length of the key value pair, it will only return the number of bytes requested or associated with that key value pair. While it may be stored on somewhat of a larger granularity, the data that is transferred would be based on a byte granularity.
Q: InfiniBand was not mentioned as a transport, is it still supported?
InfiniBand is included in the RDMA transports and is still supported.
Q: Is there any form of PI type of protection mechanism in a Key Value namespace?
We have not prohibited that. For the initial implementations of Key Value, we have not associated protection information with that value. We believe that there are many more extensions that must be done to provide protection to key value. In a logical block addressing system you put protection information with each block which is a fixed size and therefore fixed size protection information is acceptable. Since the size of the value in a KV namespace is variable length, you need protection information sufficient for up to the GB range.
Q: Are we trying to map the NVMe specification to a Storage Area Network (SAN)? What are the new features we anticipate being added with the evolution of IoT, 5G and automation use cases? Is there a need to look at different transport protocols than PCIe architecture for those use cases?
NVMe technology is continuously evolving with the ever-changing industry. NVM Express technology is in a third phase of evolution where we are enhancing NVMe technology for new use cases and can do things with NVMe technology that you couldn’t do with previous storage protocols. There is a lot of ongoing work in progress.
Q: In the earlier NVMe specifications, there was NVM subsystem reset and controller resets. With the introduction of the domain terminology to the NVMe architecture, are there any new reset types defined for the domain?
There is now the ability to reset the domain without resetting the entire subsystem.
Q: Is this presentation available for download?
You can learn more about the NVMe 2.0 specifications restructuring by accessing the webinar recording on YouTube and BrightTALK. You can download the slides from the presentation on the NVM Express Website.