Re: [PATCH] xfs: don't limit software atomic writes by the group alignment

[John Garry <john.garry@linux.dev>]

On 9/29/26 08:17, Pankaj Raghav wrote:
> 
> 
> On 9/25/2026 1:44 PM, John Garry wrote:
>> On 9/25/26 11:36, Pankaj Raghav wrote:
>>  > xfs_calc_group_awu_max() clamps the atomic write unit maximum to the
>>  > greatest power-of-two factor of the group size when the device 
>> advertises
>>  > atomic writes, so that allocations can be made naturally aligned for
>>  > REQ_ATOMIC. But that value is the software limit: it is only used when
>>  > reflink is enabled, and out of place writes through the COW fork 
>> have no
>>  > alignment requirement.
>>
>> We have mkfs atomic write options for selecting atomic write limits - 
>> you have tried that, right?
>>
> 
> Hmm, I did not try that but I restricted the agsize to a power of 2 
> value to
> workaround the limitation.
> 
> Are you talking about this option: max_atomic_write?


Yeah, so there is a mkfs and also a mount option.

For the mount option you again provide a desired awu max. From the 
desired awu max the FS checks whether that is possible (from AG count, 
etc) and then it also sizes relevant "transaction memories" for 
CoW-based atomic writes accordingly (to satisfy the awu max).

> 
> In any case, with default options the atomic values we are exposing is 
> not correct at the moment.
> 
>>>
>>> A filesystem on a > 4TB device that advertises 16k atomic writes then 
>>> reports
>>> an atomic write unit maximum of a single fsblock and an optimal 
>>> maximum of 0,
>>> and rejects any larger RWF_ATOMIC write. That is worse than the same 
>>> filesystem
>>> on a device with no atomic write support at all.
>>>
>>> Compute the software limit from the group size alone, and apply the
>>> alignment constraint in xfs_get_atomic_write_max_opt() instead, which is
>>> what reports the size that can be offloaded to the hardware.
>>>
>>> Results on a 8TB device with 16k hardware atomic support with 4k
>>> blocksize:
>>>
>>> Before patches:
>>> /media/test/hello.txt:
>>>    stx_atomic_write_unit_min:            4096
>>>    stx_atomic_write_unit_max:            4096
>>>    stx_atomic_write_unit_max_opt:        0
>>>    stx_atomic_write_segments_max:        1
>>>
>>> After patches:
>>> /media/test/hello.txt:
>>>    stx_atomic_write_unit_min:            4096
>>>    stx_atomic_write_unit_max:            2097152
>>
>> Here the AG size may not be a multiple of 2097152B, right? If so, when 
>> we try to naturally align the allocation for a CoW write, even if the 
>> AG blocks are naturally aligned (per AG), the disk blocks may not be 
>> naturnally aligned - is this correct? For HW-based atomic writes, we 
>> want naturally aligned disk blocks.
>>
> 
> Correct.
> 
> Just to give more context:
> 
> Trace of calc_atomic_write_unit_max:
> 
>   mount-696   [010]   449.230543: xfs_calc_atomic_write_unit_max: dev 
> 259:0 ag max_write 262144 max_ioend 512 max_gsize 134217728 awu_max 512
> 
> 2097152 comes from awumax being 512 fsblocks.
> 
> root@debian:~# xfs_info /dev/nvme0n1
> meta-data=/dev/nvme0n1           isize=512    agcount=8, 
> agsize=268435455 blks

Well max power-of-2 factor of this is going to be 1.

>           =                       sectsz=4096  attr=2, projid32bit=1
>           =                       crc=1        finobt=1, sparse=1, rmapbt=0
>           =                       reflink=1    bigtime=1 inobtcount=1 
> nrext64=0
> data     =                       bsize=4096   blocks=2147483640, imaxpct=5
>           =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
> log      =internal log           bsize=4096   blocks=521728, version=2
>           =                       sectsz=4096  sunit=1 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> 
>>>    stx_atomic_write_unit_max_opt:        4096
>>>    stx_atomic_write_segments_max:        1
>>>
>>> Results on a 8TB device with 16k hardware atomic support with 16k
>>> blocksize:
>>>
>>> Before patches:
>>> /media/test/hello.txt:
>>>    stx_atomic_write_unit_min:            16384
>>>    stx_atomic_write_unit_max:            16384
>>>    stx_atomic_write_unit_max_opt:        0
>>>    stx_atomic_write_segments_max:        1
>>>
>>> After patches:
>>> /media/test/hello.txt:
>>>    stx_atomic_write_unit_min:            16384
>>>    stx_atomic_write_unit_max:            33554432
>>>    stx_atomic_write_unit_max_opt:        16384
>>>    stx_atomic_write_segments_max:        1
>>>
> -- 
> Pankaj