What should we do about the nvme atomics mess?

John Garry john.g.garry at oracle.com
Thu Jan 22 02:16:53 PST 2026


On 22/01/2026 10:06, Nilay Shroff wrote:
>> Thanks for the update. It's good to know that this vendor will provide the required FW update.
>>
> An update...
> 
> IBM has now formally received a firmware update that adheres to the (proposed) Linux
> NVMe driver requirements for atomic write support. With this updated firmware, the
> controller now reports AWUPF = 0 in the Identify Controller data structure. All
> namespace-specific atomic write limits, including NAWUPF, are reported exclusively
> via the Identify Namespace data structure.
> Additionally, the atomic write limits are now correctly scaled based on the LBA format,
> as expected. The results below illustrate this behavior:
> 
> $ nvme list
> Node                  Generic               SN                   Model                                    Namespace  Usage                      Format           FW Rev
> --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- --------
> /dev/nvme5n2          /dev/ng5n2            3D60A04906N1         1.6TB NVMe Gen4 U.2 SSD IV               0x1         12.44  GB / 204.84  GB      4 KiB +  0 B   REV.BAS8
> /dev/nvme5n3          /dev/ng5n3            3D60A04906N1         1.6TB NVMe Gen4 U.2 SSD IV               0x3          0.00   B /  25.61  GB    512   B +  0 B   REV.BAS8
> 
> $ nvme id-ctrl /dev/nvme5 | grep awupf
> awupf     : 0
> 
> $ nvme id-ns /dev/nvme5n2 | grep -A4 nawupf
> nawupf  : 63
> nacwu   : 63
> nabsn   : 0
> nabo    : 0
> nabspf  : 0
> 
> nvme id-ns /dev/nvme5n3 | grep -A4 nawupf
> nawupf  : 511		==>  As expected, the atomic write limit scales naturally for 512B LBA
> nacwu   : 511
> nabsn   : 0
> nabo    : 0
> nabspf  : 0
> 
> With this update, atomic write support is now clearly and unambiguously expressed
> at the namespace level, while the controller-level AWUPF is set to zero, avoiding
> ambiguity and aligning with the Linux NVMe driver expectations. 

Thanks for the info. And it's good to hear about this FW update.

> Based on this
> outcome, we could consider:
> 
> - Recommending other vendors adopt the same reporting model, and
> - As it was already proposed earlier, updating the Linux NVMe kernel driver to disregard
>    atomic write support for devices that report a non-zero AWUPF at the controller level.

Yeah, we can just stop using AWUPF always. Or can further consider my 
proposed change to allow AWUPF to be used based on an opt-in, below.

Keith, Christoph, Any further thoughts on this?

https://lore.kernel.org/linux-nvme/20250820150220.1923826-1-john.g.garry@oracle.com/

Cheers,
John



More information about the Linux-nvme mailing list