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