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.
