NVMe 2.0, the Next-generation M.2 SSD Interface

One of the problems with NVMe memory is that today’s PCs communicate with all types of NAND Flash memory as if they were abstractions of a hard disk, which does not allow them to take advantage of all the characteristics of this type of non-volatile memory. . The NVMe 2.0 standard seeks to solve this problem and for the PC to see NVMe SSDs for what they really are, not as hard drives.

What is the NVMe 2.0 specification?

It should be clarified, to begin with, that the NVMe 2.0 specification does not define at any time how the memory chips used in NVMe SSDs are, nor how data transfer is. But they do define a series of communication protocols between the host system and the SSD. Being the guest system nothing more than the processor in charge of making the memory request, this can be a CPU, a GPU, a DMA unit, and so on.

So it is a series of different specifications that mark the different aspects that an SSD drive or any other system that uses NVMe memory must meet to comply with the NVMe 2.0 specification. Which is the most important change in it since the release of version 1.0 in 2011, and it has to be clarified that it is backward compatible with the previous ones of the protocol.

The basis for these specifications is the NVM Express Base (NVMe Base), which defines a series of new protocols for communicating with NVMe memory. These are the ones that we will deal with in this article, since the rest are optional and are not part of the base specification, but the Key-Values and Zoned Namespaces are.

What are the optional specifications? There are mainly three:

• The NVM Express Management Interface (NVMe-MI) defines an optional additional interface for managing all systems that make use of the NVM Express interfaces.
• Instead the data structures, characteristics, log pages, commands, and status values for the data I / O are specified in the NVM Express I / O Command.
• The NVM Express Transport is a series of specifications for the flash memory controller properties.

Zoned Namespaces in the NVMe 2.0 standard

One of the novelties of the NVMe 2.0 standard is the implementation of the Zoned Namespaces command, which allows the PC to divide the memory organization in the SSD into different zones under the NVMe 2.0 standard, although its implementation began to occur in version 1.4 of the NVMe standard its final version is given in the version that we are dealing with in this article.

The idea is none other than dividing the SSD storage into different areas, think of them as partitions. When the PC asks to write the data in a namespace zone, what the flash memory controller will do is write sequentially in said zone, which will be delimited in size and will not be able to write more data if it exceeds the pre-allocated size, regardless of whether there is more flash memory available.

The purpose of this? One of the advantages is that this means that the flash memory controller does not have to manage writes to random memory addresses and the use of space is optimized. The CPU simply reserves a delimited part of the storage as an area to store the data. When accessing that zone is needed, the PC will tell the flash memory controller that it wants to access the data for that particular zone.

Key-Value changes the way data is accessed in NVMe 2.0

Another of the improvements built into NVMe 2.0 is the Key-Value or Key-Value command. Which is based on accessing the data stored on the SSD through a unique key instead of the virtual address of the data block. It is something that comes from the world of databases and this novelty allows applications to communicate with the SSD through a key-value. Which means saying goodbye to the translation tables between the keys issued by the processor and the physical address of the memory.

To better understand the concept we have to take into account that traditionally information is stored in an SSD by blocks, something that comes from the world of hard drives and that implies the following:

• The data is stored in blocks or pages of memory of regular size, on the other hand, a group of data associated with a key-value can be any size.
• The data in the block system is accessed from a virtual memory address, while in NVMe 2.0 the data can be accessed by knowing the key-value to access them.
• With storage making use of key values we can store any number of bytes, on the other hand, in classic memory paging we can only store data in multiples of the size of each block.

The Key-Value is based on two different values, the first is the key that is assigned to each device and can have a size between 1 byte and 32 bytes. For each NVMe 2.0 device you will be generated a unique key to access your data. The second instead is the value that allows access to a specific data block.

Support for conventional disk drives

It will take years to see conventional hard drives disappear and many of them are still used in many tandem systems alongside SSDs. However, the new rules for data access brought by the NVMe 2.0 standard differ greatly from the way data is stored on hard drives.

The support for rotational formats is based on two things, the first of which is to give the hard drives the ability to access the same physical space on the I / O peripherals as the M.2 NVMe SSDs, that is, the port PCI Express, which does not mean that we are going to see disks with a PCIe interface, but we are going to see in the PCs of the future interfaces for transferring from SATA to PCIe that will allow data to be copied between both storage devices faster.

The other is support for the new NVMe 2.0 data addressing in the form of Zoned Namespaces and Key Values, so that both types of storages can be understood within the same system. That is, the NVMe 2.0 assumes that the SSD stops speaking in the language of the HDD for the reverse to occur.