[PATCH v2] nvme: stop using AWUPF
Nilay Shroff
nilay at linux.ibm.com
Wed Jan 28 01:35:36 PST 2026
On 1/28/26 1:56 PM, John Garry wrote:
> As described at [0], much of the atomic write parts of the specification
> are lacking.
>
> For now, there is nothing which we can do in software about the lack of
> a dedicated NVMe write atomic command.
>
> As for reading the atomic write limits, it is felt that the per-namespace
> values are mostly properly specified and it is assumed that they are
> properly implemented.
>
> The specification of NAWUPF is quite clear. However the specification of
> NABSPF is less clear. The lack of clarity in NABSPF comes from deciding
> whether NABSPF applies when NSABP is 0 - it is assumed that NSABPF does
> not apply when NSABP is 0.
>
> As for the per-controller AWUPF, how this value applies to shared
> namespaces is missing in the specification. Furthermore, the value is in
> terms of logical blocks, which is an NS entity.
>
> Since AWUPF is so poorly defined, stop using it already together.
> Hopefully this will force vendors to implement NAWUPF support always.
>
> Note that AWUPF not only effects atomic write support, but also the
> physical block size reported for the device.
>
> To help users know this restriction, log an info message per NS.
>
> [0] https://lore.kernel.org/linux-nvme/20250707141834.GA30198@lst.de/
>
> Signed-off-by: John Garry <john.g.garry at oracle.com>
> ---
Looks good to me.
Tested this patch on NVMe device reporting non-zero NAWUPF (and zero
AWUPF), as well as on device reporting non-zero AWUPF. In both cases,
the patch works as expected.
Tested-by: Nilay Shroff <nilay at linux.ibm.com>
Reviewed-by: Nilay Shroff <nilay at linux.ibm.com>
More information about the Linux-nvme
mailing list