On Mon, Mar 14, 2022 at 07:30:25PM +0000, Matias Bjørling wrote: > > -----Original Message----- > > From: Luis Chamberlain <mcgrof@xxxxxxxxxxxxx> On Behalf Of Luis > > Chamberlain > > Sent: Monday, 14 March 2022 17.24 > > To: Matias Bjørling <Matias.Bjorling@xxxxxxx> > > Cc: Javier González <javier@xxxxxxxxxxx>; Damien Le Moal > > <damien.lemoal@xxxxxxxxxxxxxxxxxx>; Christoph Hellwig <hch@xxxxxx>; > > Keith Busch <kbusch@xxxxxxxxxx>; Pankaj Raghav <p.raghav@xxxxxxxxxxx>; > > Adam Manzanares <a.manzanares@xxxxxxxxxxx>; > > jiangbo.365@xxxxxxxxxxxxx; kanchan Joshi <joshi.k@xxxxxxxxxxx>; Jens > > Axboe <axboe@xxxxxxxxx>; Sagi Grimberg <sagi@xxxxxxxxxxx>; Pankaj > > Raghav <pankydev8@xxxxxxxxx>; Kanchan Joshi <joshiiitr@xxxxxxxxx>; linux- > > block@xxxxxxxxxxxxxxx; linux-nvme@xxxxxxxxxxxxxxxxxxx > > 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. Exactly. So taking a position to not support NPO2 I think seems counter productive to the future of ZNS, the question whould be, *how* to best do this in light of what we need to support / avoid performance regressions / strive towards avoiding fragmentation. > 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. I'm not, but I admit that it's a good point of having the possibility of zones being taken offline also implicates holes. I also think it was a good excercise to discuss and evaluate emulation given I don't think this point you made would have been made clear otherwise. This is why I treat ZNS as evolving effort, and I can't seriously take any position stating all answers are known. > 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. NAND does not incur a PO2 requirement, that should be enough to implicate that PO2 zones *can* be expected. If no vendor wants to take a position that they know for a fact they'll never adopt PO2 zones should be enough to keep an open mind to consider *how* to support them. > > > 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. I'm not quite sure that is the case. To reach consensus one has to take a position of accepting the right answer may not be known and we evaluate all prospects. It is not clear to me that we've done that yet and it is why I think a venue such as LSFMM may be good to review these things. > 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. Sorry I didn't understand the suggestion here, can you clarify what it is you are suggesting? Thanks! Luis
