On Wed, Mar 16, 2022 at 09:46:44AM +0900, Damien Le Moal wrote: > On 3/16/22 09:23, Luis Chamberlain wrote: > > 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. I can tell you we there is an existing NPO2 ZNS customer which chimed on the discussion and they described having to carry a delta to support NPO2 ZNS. So if you cannot tell me of a ZNS application which is going to break to add NPO2 support then your original point is not valid of suggesting that there would be a break. > > Why would that break those ZNS applications? > > Please keep in mind that there are power of 2 zone sized ZNS devices out > there. No one is saying otherwise. > Applications designed for these devices and optimized to do bit > shift arithmetic using the power of 2 size property will break. They must not be ZNS. So they can continue to chug on. > What the > plan for that case ? How will you address these users complaints ? They are not ZNS so they don't have to worry about ZNS. ZNS applications must be aware of that fact that NPO2 can exist. ZNS applications must be aware of that fact that any vendor may one day sell NPO2 devices. > >> 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. Ugly is relative and subjective. NAND does not force PO2. > The kernel <etc> And back you go to kernel talk. I thought you wanted to focus on applications. > Applications correctly designed for SMR can thus also run on ZNS too. That seems to be an incorrect assumption given ZNS drives exist with NPO2. So you can probably say that some SMR applications can work with PO2 ZNS drives. That is a more correct statement. > With this in mind, the spectrum of applications that would break on non > power of 2 ZNS devices is suddenly much larger. We already determined you cannot identify any ZNS specific application which would break. SMR != ZNS If you really want to use SMR applications for ZNS that seems to be a bit beyond the scope of this discussion, but it seems to me that those SMR applications should simply learn that if a device is ZNS that NPO2 can be expected. As technologies evolve so do specifications. > 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. It's a reality though. Devices exist, and so do users. And they're carrying their own delta to support NPO2 ZNS today on Linux. > > 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. This conversation is about the reality that ZNS NPO2 exist and how best to support that. You seem to want to negate that reality and support on Linux without even considering what the changes look like to to support ZNS NPO2. As a maintainer I think we need to *evaluate* supporting users as best as possible. Not denying their existance. Even if it pains us. Luis
