Re: [bug report] fstests generic/774 hang again

[Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

On Sep 25, 2026 / 16:03, Darrick J. Wong wrote:
[...]
> 
> Yeah, I think you're on the right track with the dynamic tr_logcount
> changes but I wonder if you want to constrain the max software atomic
> write size so that we don't end up with gigantic chains that consume
> significant portions of the log for a single write?
> 
> Admittedly I see the multi-megabyte atomic write limits and marvel at
> how far we've drifted from the original requirements.

Darrick, thank you for the comments, and sorry for my slow response. Today,
I found some time slot to try out max atomic write bytes capping. I took a
look in your code snippet below, and was scratching my head.

> 
> --D
> 
> diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c
> index 1c20a7c27aa1bf..2e84544cd22a0a 100644
> --- a/fs/xfs/libxfs/xfs_trans_resv.c
> +++ b/fs/xfs/libxfs/xfs_trans_resv.c
> @@ -1473,6 +1473,10 @@ xfs_calc_max_atomic_write_fsblocks(
>         struct xfs_mount                *mp)
>  {
>         const struct xfs_trans_res      *resv = &M_RES(mp)->tr_atomic_ioend;
> +       const unsigned int              max_log_bytes =
> +               XFS_FSB_TO_B(mp, mp->m_sb.sb_logblocks * 10 / 4);
> +       const unsigned int              log_bytes_per_aw_block =
> +               (resv->tr_logres * resv->tr_logcount * 5) / 4;

I wonder what the numbers in the two lines above mean. I think 5 means the
number of transaction rolls required for an atomic write. But not sure about 10
and 4. May I ask you to elaborate them?

Anyway, I applied this patch, and confirmed that awu_max reduced from 1024 to
64 in my test setup (4MiB to 256KiB). So, it looks working as expected.