> -----Original Message----- > From: Heiner Litz <hlitz@xxxxxxxx> > Sent: Friday, 19 June 2020 00.05 > To: Keith Busch <kbusch@xxxxxxxxxx> > Cc: Damien Le Moal <Damien.LeMoal@xxxxxxx>; Javier González > <javier@xxxxxxxxxxx>; Matias Bjørling <mb@xxxxxxxxxxx>; Matias Bjorling > <Matias.Bjorling@xxxxxxx>; Christoph Hellwig <hch@xxxxxx>; Keith Busch > <Keith.Busch@xxxxxxx>; linux-nvme@xxxxxxxxxxxxxxxxxxx; linux- > block@xxxxxxxxxxxxxxx; Sagi Grimberg <sagi@xxxxxxxxxxx>; Jens Axboe > <axboe@xxxxxxxxx>; Hans Holmberg <Hans.Holmberg@xxxxxxx>; Dmitry > Fomichev <Dmitry.Fomichev@xxxxxxx>; Ajay Joshi <Ajay.Joshi@xxxxxxx>; > Aravind Ramesh <Aravind.Ramesh@xxxxxxx>; Niklas Cassel > <Niklas.Cassel@xxxxxxx>; Judy Brock <judy.brock@xxxxxxxxxxx> > 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).
