What should we do about the nvme atomics mess?

[Keith Busch]

On Mon, Jul 07, 2025 at 05:26:46PM +0200, Hannes Reinecke wrote:
> On 7/7/25 16:24, Keith Busch wrote:
> > On Mon, Jul 07, 2025 at 04:18:34PM +0200, Christoph Hellwig wrote:
> > > We could:
> > > 
> > >   I.	 revert the check and the subsequent fixup.  If you really want
> > >           to use the nvme atomics you already better pray a lot anyway
> > > 	 due to issue 1)
> > >   II.	 limit the check to multi-controller subsystems
> > >   III.	 don't allow atomics on controllers that only report AWUPF and
> > >   	 limit support to controllers that support that more sanely
> > > 	 defined NAWUPF
> > > 
> > > I guess for 6.16 we are limited to I. to bring us back to the previous
> > > state, but I have a really bad gut feeling about it given the really
> > > bad spec language and a lot of low quality NVMe implementations we're
> > > seeing these days.
> > 
> > I like option III. The controler scoped atomic size is broken for all
> > the reasons you mentioned, so I vote we not bother trying to make sense
> > of it.
> > 
> Agree. We might consider I. as a fixup for stable, but should continue
> with III going forward.

I think the NVMe TWG might want to consider an ECN to deprecate or at
least recommend against AUWPF, too.

Just to throw AWUPF a lifeline for legecy devices, we could potentially
make sense of the value if Identify Controller says:

  1. CMIC == 0; and
  2. OACS.NMS == 0; and
  3.
    a. FNA.FNS == 1; or
    b. NN == 1

And if those conditions are true, then the controller and namespace
scopes resolve to a single namespace format, so the values should be one
in the same. The only way it could change, then, is a format command,
which means there couldn't be an in-use filesystem depending on it not
changing.