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

[Pankaj Raghav <pankaj.raghav@linux.dev>]

On 9/30/2026 10:42 AM, John Garry wrote:
> On 9/30/26 06:10, Pankaj Raghav (Samsung) wrote:
>>>> 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.
>>>
>>
>> Exactly. I get that we should restrict max_opt to be 1 because the AG's
>> will not be aligned and the best we can do is one fsblock for HW based
>> atomics. Why should we restrict the max (SW atomics limit) to 1 fsblock?
>>
> 
> Maybe in this case we don't need to restrict CoW-based atomics to 1 fsblock. But 
> why care? I mean, you have HW support, which is so much better to use than CoW- 
> based atomics, so better to config your FS to avail of them.

That is true but it is a bit strange we expose a smaller CoW based atomics when 
we have HW based atomic support.

For me the main issue is this function:
static xfs_extlen_t
xfs_calc_group_awu_max(
	struct xfs_mount	*mp,
	enum xfs_group_type	type)
{
	struct xfs_groups	*g = &mp->m_groups[type];
	struct xfs_buftarg	*btp = xfs_group_type_buftarg(mp, type);

	if (g->blocks == 0)
		return 0;
	if (btp && btp->bt_awu_min > 0)
		return max_pow_of_two_factor(g->blocks);
	return rounddown_pow_of_two(g->blocks);
}

Why do we take into account hardware limits when we calculate SW atomic limits?

For more context:

In my drive, I am getting odd nr_blks agsize for the drive I have when I format
it with 16k block size. This is fine because block size is aligned
with HW atomic write size. The issue comes in xfs_calc_group_awu_max where
we do max_pow_of_two_factor on blocks if HW based atomics are enabled, thereby,
awu_max is reported as 1.


So this results in the following

panky@blixen:~$ mkfs.xfs -V
mkfs.xfs version 7.1.1

panky@blixen:~$ xfs_info /mnt/atomssd/
meta-data=/dev/nvme1n1           isize=512    agcount=14, agsize=67108863 blks
          =                       sectsz=4096  attr=2, projid32bit=1
          =                       crc=1        finobt=1, sparse=1, rmapbt=1
          =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
          =                       exchange=1   metadir=0
data     =                       bsize=16384  blocks=937558016, imaxpct=5
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=16384  ascii-ci=0, ftype=1, parent=1
log      =internal log           bsize=16384  blocks=130432, version=2
          =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=16384  blocks=0, rtextents=0
          =                       rgcount=0    rgsize=0 extents
          =                       zoned=0      start=0 reserved=0


root@blixen:~# trace-cmd report
cpus=8
            mount-4432  [005] ..... 24183.039820: 
xfs_calc_atomic_write_unit_max: dev 259:2 ag max_write 131072 max_ioend 4096 
max_gsize 1 awu_max 1
            mount-4432  [005] ..... 24183.039820: 
xfs_calc_atomic_write_unit_max: dev 259:2 rtg max_write 131072 max_ioend 4096 
max_gsize 0 awu_max 0

panky@blixen:~/tools$ sudo ./statx /mnt/atomssd/hello.txt
/mnt/atomssd/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


I hope I have explained the issue clearly now.

--
Pankaj