On 30/12/2025 09:01, Vitaliy Filippov wrote:

I think that even with the 2^N requirement the user still has to look
for boundaries.
1) NVMe disks may have NABO != 0 (atomic boundary offset). In this
case 2^N aligned writes won't work at all.

We don't support NABO != 0

2) NABSPF is expressed in blocks in the NVMe spec and it's not
restricted to 2^N, it can be for example 3 (3*4096 = 12 KB). The spec
allows it. 2^N breaks this case too.

We could support NABSPF which is not a power-of-2, but we don't today.

If you can find some real HW which has NABSPF which is not a power-of-2, 
then it can be considered.

And the user also has to look for the maximum atomic write size
anyway, he can't just assume all writes are atomic out of the box,
regardless of the 2^N requirement.
So my idea is that the kernel's task is just to guarantee correctness
of atomic writes. It anyway can't provide the user with atomic writes
in all cases.

What good is that to a user?

Consider the user wants to atomic write a range of a file which is 
backed by disk blocks which straddle a boundary - in this case, the 
write would fail. What is the user supposed to do then? That API could 
have arbitrary failures, which effectively makes it a useless API.

As I said before, just don't use RWF_ATOMIC if you don't want to deal 
with these restrictions.