The Next Step In SSD Evolution: NVMe Zoned Namespaces Explained

FallOutBoyTonto writes: In June we saw an update to the NVMe standard. The update defines a software interface to assist in actually reading and writing to the drives in a way to which SSDs and NAND flash actually works. Instead of emulating the traditional block device model that SSDs inherited from hard drives and earlier storage technologies, the new NVMe Zoned Namespaces optional feature allows SSDs to implement a different storage abstraction over flash memory. This is quite similar to the extensions SAS and SATA have added to accommodate Shingled Magnetic Recording (SMR) hard drives, with a few extras for SSDs. 'Zoned' SSDs with this new feature can offer better performance than regular SSDs, with less overprovisioning and less DRAM. The downside is that applications and operating systems have to be updated to support zoned storage, but that work is well underway.

The NVMe Zoned Namespaces (ZNS) specification has been ratified and published as a Technical Proposal. It builds on top of the current NVMe 1.4a specification, in preparation for NVMe 2.0. The upcoming NVMe 2.0 specification will incorporate all the approved Technical Proposals, but also reorganize that same functionality into multiple smaller component documents: a base specification (one for each command set of block, zoned, key-value, and potentially more in the future), and separate specifications for each transport protocol (PCIe, RDMA, TCP). The standardization of Zoned Namespaces clears the way for broader commercialization and adoption of this technology, which so far has been held back by vendor-specific zoned storage interfaces and very limited hardware choices. [...]

The essence of ZNS

[hankwang]

I read through TFA and I find it rather difficult to grasp the essence of Zoned Namespaces.

I think the essence is that NAND memory has large erase blocks, but writes can be in small pages, but the pages are essentially write-once until the entire block is erased. ZNS seems to expose an append-only interface for writing data. The SSD controller still takes care of wear leveling, but does not need to deal with garbage collection of discarded pages.

Apparently, there are all kinds of restrictions related to how NAND memory works: reading data in a block ("zone") that is still in the 'being appended to' state can create data errors. Also, there is a limit to how many zones can be open for writing/appending at the same time.

Apparently, the OS kernel can hide all the quirks of ZNS and expose it as a traditional filesystem. But how much of the benefit will disappear if you do this? The article mentions (on the 'ecosystem' page) that the OS kernel may expose the ZNS interface to certain applications that are ZNS-aware, but this sounds very difficult to me, given the limit on number of open zones and all the precautions needed to prevent data corruption.

Re:

[JustAnotherOldGuy]

I read through TFA and I find it rather difficult to grasp the essence of Zoned Namespaces

Same here...I didn't expect I'd be an expert on it after reading the article, but I confess I didn't really get the whole idea and why it's superior to whatever we're using now.

Re:

[gillbates]

It seemed to me that this model allows for host-level optimization of SSD performance. At the expense of a sane filesystem abstraction.

By exposing the details of how the underlying flash actually works to the OS, the operating system can now do what the SSD controller used to do. However, the OS actually has more information about the data read/written than the SSD. For example, /var is often used for logs, printer queues, etc... - files which are seldom modified, but must be written in a timely manne

Re:

[account_deleted]

Comment removed based on user account deletion

Re: The essence of ZNS

[sectokia]

Itâ(TM)s not up... No where do they actually explain it. A ZNS is really just a block of LBAs being written as one large chunk. Currently on an SSD if you write a 512b lba (or even 4096b) , the SSD has much larger flash cells, so it has to buffer those writes up until it can either fill the cell, or it has to just write a cell and have some space left unused. Eventually it can combine two half filled cells, but that requires a flash erase and then 2 reads then 1 writes, then updating the LBA mappin

Re:The essence of ZNS

[sonofusion82]

Apparently, the OS kernel can hide all the quirks of ZNS and expose it as a traditional filesystem. But how much of the benefit will disappear if you do this?

As far as I know, the main target use case is not for OS kernel to use it as a backend for traditional filesystem. This will just move the responsibility for handling the flash block management from a highly specialized SSD controller with HW accelerators to an inefficient general purpose host CPU. Some high-end SSD have several GB of DRAM to keep track for flash block managements. I won't want my host OS to use large chunk of RAM just for flash management.

The main target application for ZNS is for certain data center applications that usually performs large sequential block writes. This will significantly reduces many flash management overheads on the storage stack but the application will need to be aware for the ZNS/SMR behavior.

So, the title of the OP is a little incorrect. It is not an evolution for SSD but more like an additional feature for certain specialized application. It is not meant to replace current conventional SSDs.

PS: I work for WD SSD but not involve in ZNS.

Re:

[account_deleted]

Comment removed based on user account deletion