[PATCH 0/6] power_of_2 emulation support for NVMe ZNS devices

[Matias Bjørling]

> -----Original Message-----
> From: Luis Chamberlain <mcgrof at infradead.org> On Behalf Of Luis
> Chamberlain
> Sent: Monday, 14 March 2022 17.24
> To: Matias Bjørling <Matias.Bjorling at wdc.com>
> Cc: Javier González <javier at javigon.com>; Damien Le Moal
> <damien.lemoal at opensource.wdc.com>; Christoph Hellwig <hch at lst.de>;
> Keith Busch <kbusch at kernel.org>; Pankaj Raghav <p.raghav at samsung.com>;
> Adam Manzanares <a.manzanares at samsung.com>;
> jiangbo.365 at bytedance.com; kanchan Joshi <joshi.k at samsung.com>; Jens
> Axboe <axboe at kernel.dk>; Sagi Grimberg <sagi at grimberg.me>; Pankaj
> Raghav <pankydev8 at gmail.com>; Kanchan Joshi <joshiiitr at gmail.com>; linux-
> block at vger.kernel.org; linux-nvme at lists.infradead.org
> Subject: Re: [PATCH 0/6] power_of_2 emulation support for NVMe ZNS devices
> 
> On Mon, Mar 14, 2022 at 02:16:36PM +0000, Matias Bjørling wrote:
> > I want to turn the argument around to see it from the kernel
> > developer's point of view. They have communicated the PO2 requirement
> > clearly,
> 
> Such requirement is based on history and effort put in place to assume a PO2
> requirement for zone storage, and clearly it is not. And clearly even vendors
> who have embraced PO2 don't know for sure they'll always be able to stick to
> PO2...

Sure - It'll be naïve to give a carte blanche promise.

However, you're skipping the next two elements, which state that there are both good precedence working with PO2 zone sizes and that holes/unmapped LBAs can't be avoided. Making an argument for why NPO2 zone sizes may not bring what one is looking for. It's a lot of work for little practical change, if any. 

> 
> > there's good precedence working with PO2 zone sizes, and at last,
> > holes can't be avoided and are part of the overall design of zoned
> > storage devices. So why should the kernel developer's take on the
> > long-term maintenance burden of NPO2 zone sizes?
> 
> I think the better question to address here is:
> 
> Do we *not* want to support NPO2 zone sizes in Linux out of principal?
> 
> If we *are* open to support NPO2 zone sizes, what path should we take to
> incur the least pain and fragmentation?
> 
> Emulation was a path being considered, and I think at this point the answer to
> eveluating that path is: this is cumbersome, probably not.
> 
> The next question then is: are we open to evaluate what it looks like to slowly
> shave off the PO2 requirement in different layers, with an goal to avoid further
> fragmentation? There is effort on evaluating that path and it doesn't seem to
> be that bad.
> 
> So I'd advise to evaluate that, there is nothing to loose other than awareness of
> what that path might look like.
> 
> Uness of course we already have a clear path forward for NPO2 we can all
> agree on.

It looks like there isn't currently one that can be agreed upon.

If evaluating different approaches, it would be helpful to the reviewers if interfaces and all of its kernel users are converted in a single patchset. This would also help to avoid users getting hit by what is supported, and what isn't supported by a particular device implementation and allow better to review the full set of changes required to add the support.