What should we do about the nvme atomics mess?

Keith Busch kbusch at kernel.org
Tue Jul 8 08:19:32 PDT 2025


On Tue, Jul 08, 2025 at 11:47:48AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 07, 2025 at 09:56:53AM -0600, Keith Busch wrote:
> > 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
> 
> What is NMS meant to say?  namespace management support?

Right, namespace management support. The spec calls this field 'NMS' now.
 
> >   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.
> 
> We could.  But are there many controllers where that would be the
> case and where people want to use atomics?

Maybe not. I still have a lot of 1.0 compliant devices where this might
apply, but I don't have a use case explicitly needing the atomic write
features anyway, so it doesn't matter to me if the driver doesn't report
the limits for them.

So I guess no need to work with such devices at this point, but maybe
just something to consider in the unlikely event someone complains.



More information about the Linux-nvme mailing list