On 3/16/22 09:23, Luis Chamberlain wrote: > On Wed, Mar 16, 2022 at 09:07:18AM +0900, Damien Le Moal wrote: >> On 3/16/22 02:00, Luis Chamberlain wrote: >>> On Tue, Mar 15, 2022 at 02:30:52PM +0100, Christoph Hellwig wrote: >>>> On Tue, Mar 15, 2022 at 02:26:11PM +0100, Javier González wrote: >>>>> but we do not see a usage for ZNS in F2FS, as it is a mobile >>>>> file-system. As other interfaces arrive, this work will become natural. >>>>> >>>>> ZoneFS and butrfs are good targets for ZNS and these we can do. I would >>>>> still do the work in phases to make sure we have enough early feedback >>>>> from the community. >>>>> >>>>> Since this thread has been very active, I will wait some time for >>>>> Christoph and others to catch up before we start sending code. >>>> >>>> Can someone summarize where we stand? >>> >>> RFCs should be posted to help review and evaluate direct NPO2 support >>> (not emulation) given we have no vendor willing to take a position that >>> NPO2 will *never* be supported on ZNS, and its not clear yet how many >>> vendors other than Samsung actually require NPO2 support. The other >>> reason is existing NPO2 customers currently cake in hacks to Linux to >>> supoport NPO2 support, and so a fragmentation already exists. To help >>> address this it's best to evaluate what the world of NPO2 support would >>> look like and put the effort to do the work for that and review that. >> >> And again no mentions of all the applications supporting zones assuming >> a power of 2 zone size that will break. > > What applications? ZNS does not incur a PO2 requirement. So I really > want to know what applications make this assumption and would break > because all of a sudden say NPO2 is supported. Exactly. What applications ? For ZNS, I cannot say as devices have not been available for long. But neither can you. > Why would that break those ZNS applications? Please keep in mind that there are power of 2 zone sized ZNS devices out there. Applications designed for these devices and optimized to do bit shift arithmetic using the power of 2 size property will break. What the plan for that case ? How will you address these users complaints ? >> Allowing non power of 2 zone size may prevent applications running today >> to run properly on these non power of 2 zone size devices. *not* nice. > > Applications which want to support ZNS have to take into consideration > that NPO2 is posisble and there existing users of that world today. Which is really an ugly approach. The kernel zone user interface is common to all zoned devices: SMR, ZNS, null_blk, DM (dm-crypt, dm-linear). They all have one point in common: zone size is a power of 2. Zone capacity may differ, but hey, we also unified that by reporting a zone capacity for *ALL* of them. Applications correctly designed for SMR can thus also run on ZNS too. With this in mind, the spectrum of applications that would break on non power of 2 ZNS devices is suddenly much larger. This has always been my concern from the start: allowing non power of 2 zone size fragments userspace support and has the potential to complicate things for application developers. > > You cannot negate their existance. > >> I have yet to see any convincing argument proving that this is not an issue. > > You are just saying things can break but not clarifying exactly what. > And you have not taken a position to say WD will not ever support NPO2 > on ZNS. And so, you can't negate the prospect of that implied path for > support as a possibility, even if it means work towards the ecosystem > today. Please do not bring in corporate strategy aspects in this discussion. This is a technical discussion and I am not talking as a representative of my employer nor should we ever dicsuss business plans on a public mailing list. I am a kernel developer and maintainer. Keep it technical please. -- Damien Le Moal Western Digital Research
