The future of SSDs is no longer in the air, NVMe 2.0 arrives for your M.2

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 from 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 must 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. Since the guest system is 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 must be clarified that it is backward compatible with the previous ones of the protocol.

NVMe hard drives

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 the management of 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

Zoned Namespaces NVMe 2.0

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 organization of memory 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.

Zoned Namespaces NVMe 2.0

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 ensures 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 of 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

NVMe 2.0 rotational media

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

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 NVMe M.2 SSDs, that is, the port PCI Express, which does not mean that we will see disks with a PCIe interface, but it does mean that we will 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.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *