Re: [PATCH 5/5] nvme: support for zoned namespaces

["Matias Bjørling" <mb@lightnvm.io>]

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 <Matias.Bjorling@wdc.com> wrote:
>>> -----Original Message-----
>>> From: Heiner Litz <hlitz@ucsc.edu>
>>> Sent: Friday, 19 June 2020 00.05
>>> To: Keith Busch <kbusch@kernel.org>
>>> Cc: Damien Le Moal <Damien.LeMoal@wdc.com>; Javier González
>>> <javier@javigon.com>; Matias Bjørling <mb@lightnvm.io>; Matias Bjorling
>>> <Matias.Bjorling@wdc.com>; Christoph Hellwig <hch@lst.de>; Keith Busch
>>> <Keith.Busch@wdc.com>; linux-nvme@lists.infradead.org; linux-
>>> block@vger.kernel.org; Sagi Grimberg <sagi@grimberg.me>; Jens Axboe
>>> <axboe@kernel.dk>; Hans Holmberg <Hans.Holmberg@wdc.com>; Dmitry
>>> Fomichev <Dmitry.Fomichev@wdc.com>; Ajay Joshi <Ajay.Joshi@wdc.com>;
>>> Aravind Ramesh <Aravind.Ramesh@wdc.com>; Niklas Cassel
>>> <Niklas.Cassel@wdc.com>; Judy Brock <judy.brock@samsung.com>
>>> 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).