On 19/06/2020 20.08, Heiner Litz wrote:

Hi Matias,
no, I am rather saying that the Linux kernel has a deficit or at least
is not a good fit for ZNS because it cannot enforce in-order delivery.
The requirement of sequential writes basically imposes this
requirement. Append essentially a Linux specific fix on the ZNS level
and that enforcing ordering would be a cleaner way to enable QD>1.

Ah, I am not sure I agree with that statement. As Keith points out, 
there is not even in-order delivery in NVMe. Any system where high 
performance is required, has out of order mechanisms that improves 
parallelism and performance. If one wants to issue I/Os in order, it is 
as easy as supplying a write-back cache. Linux and any other systems are 
able to do that.

On Fri, Jun 19, 2020 at 3:29 AM Matias Bjorling [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: Heiner Litz <redacted>
Sent: Friday, 19 June 2020 00.05
To: Keith Busch <kbusch@kernel.org>
Cc: Damien Le Moal <redacted>; Javier González
[off-list ref]; Matias Bjørling [off-list ref]; Matias Bjorling
[off-list ref]; Christoph Hellwig [off-list ref]; Keith Busch
[off-list ref]; linux-nvme@lists.infradead.org; linux-
block@vger.kernel.org; Sagi Grimberg [off-list ref]; Jens Axboe
[off-list ref]; Hans Holmberg [off-list ref]; Dmitry
Fomichev [off-list ref]; Ajay Joshi [off-list ref];
Aravind Ramesh [off-list ref]; Niklas Cassel
[off-list ref]; Judy Brock [off-list ref]
Subject: Re: [PATCH 5/5] nvme: support for zoned namespaces

Matias, Keith,
thanks, this all sounds good and it makes total sense to hide striping from the
user.

In the end, the real problem really seems to be that ZNS effectively requires in-
order IO delivery which the kernel cannot guarantee. I think fixing this problem
in the ZNS specification instead of in the communication substrate (kernel) is
problematic, especially as out-of-order delivery absolutely has no benefit in the
case of ZNS.
But I guess this has been discussed before..

I'm a bit dense, by the above, is your conclusion that ZNS has a deficit/feature, which OCSSD didn't already have? They both had the same requirement that a chunk/zone must be written sequentially. It's the name of the game when deploying NAND-based media, I am not sure how ZNS should be able to help with this. The goal of ZNS is to align with the media (and OCSSD), which makes writes required to be sequential, and one thereby gets a bunch of benefits.

If there was an understanding that ZNS would allow one to write randomly, I must probably disappoint. For random writes, typical implementations either use a write-back scheme, that stores data in random write media first, and then later write it out sequentially, or write a host-side FTL (with its usual overheads).