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

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

On 9/30/26 13:27, Pankaj Raghav wrote:
>>
>> 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);
> }


----->8-----

--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -694,7 +694,7 @@ xfs_calc_group_awu_max(

         if (g->blocks == 0)
                 return 0;
-       if (btp && btp->bt_awu_min > 0)
+       if (btp && btp->bt_awu_max > mp->m_sb.sb_blocksize)
                 return max_pow_of_two_factor(g->blocks);
         return rounddown_pow_of_two(g->blocks);
}

-----8<-----


You are advocating something like this (to solve the issue below), right?

note: that we still need to ensure that bt_awu_min <= sb_blocksize to 
get HW atomics at all (so should keep a check for bt_awu_min in 
xfs_calc_group_awu_max() or similar)

> 
> 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.