One of the problems with NVMe memory is that PCs today communicate with all types of NAND Flash memory as if they were hard drive abstractions, so they cannot take advantage of all the characteristics of this type of non-volatile memory. . The NVMe 2.0 standard seeks to address this issue and make the PC see NVMe SSDs for what they really are, not hard drives.
What is the NVMe 2.0 specification?
It should be noted, first of all, that the NVMe 2.0 specification at no time defines how memory chips are used in NVMe SSDs, nor how data is transferred. But they 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, it can be a CPU, GPU, DMA unit, etc.
So this is a series of different specifications that mark the different aspects that an SSD or any other system using NVMe memory must meet in order to comply with the NVMe 2.0 specification. This is the most important change since the release of version 1.0 in 2011, and it should be noted that it is backward compatible with the precedents of the protocol.
The basis of these specifications is NVM Express Base (NVMe Base), which defines a series of new protocols for communicating with NVMe memory. These are the ones we’ll cover in this article, because the rest are optional and not part of the base spec, but key-values and zoned namespaces are.
What are the optional specifications? There are mainly three:
- NVM Express Management Interface (NVMe-MI) defines an optional additional interface for the management of all systems that use NVM Express interfaces.
- Instead, data structures, characteristics, log pages, commands, and data I / O status values are specified in the NVM Express I / O command.
- NVM Express Transport is a series of specifications for the properties of the flash memory controller.
Zoned Namespaces in NVMe 2.0
One of the new features 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 work started to occur in version 1.4 of the NVMe Standard its final version is given in the version that we deal with in this article.
The idea is none other than to divide the SSD storage into different areas, think of them as partitions. When the PC asks to write data to a namespace area, what the flash memory controller will do is write sequentially to that area, which will be delimited in size and cannot write more than data if it exceeds the pre-allocated size, whether or not 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 handle writes to random memory addresses and that space usage is optimized. The CPU simply reserves a delimited part of the storage as an area to store data. When it is necessary to access this area, the PC will indicate to the flash memory controller that it wishes to access the data in that particular area.
Key-Value changes the way data is accessed in NVMe 2.0
Another of the enhancements built into NVMe 2.0 is the Key-Value or Key-Value command. Which is based on accessing the data stored on the SSD via a unique key instead of the virtual address of the data block. This is something that comes from the world of databases and this novelty allows applications to communicate with the SSD via a key-value. Which amounts to saying goodbye to translation tables between the keys emitted 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 in blocks, something that comes from the world of hard drives and involves the following:
- Data is stored in regularly sized blocks or pages of memory, however, a data group associated with a key value can be any size.
- Block system data is accessed from a virtual memory address, whereas in NVMe 2.0 the data is accessed by knowing the key-value to access it.
- With storage using 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, a unique key will be generated for you to access your data. The second instead is the value that allows access to a specific block of data.
Support for conventional disk drives
It will take years for conventional hard drives to disappear and many of them are still used in many systems in tandem alongside SSDs. However, the new data access rules brought by the NVMe 2.0 standard differ greatly from the way data is stored on hard drives.
Support for rotational formats relies on two things, the first being to give hard drives the ability to access the same physical space on I / O devices as M.2 NVMe SSDs, i.e. – say the PCI Express port, which does not mean that we are going to see disks with a PCIe interface, but it does mean that we are going to see SATA to PCIe transfer interfaces in future PCs that will allow data to be copied more quickly between the two storage devices.
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, NVMe 2.0 assumes that the SSD stops speaking in the language of the hard drive for the reverse to happen.
Table of Contents
