Re: [PATCH 7/7] mkfs: allow users to configure the desired maximum atomic write size

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Jul 02, 2025 at 09:50:04AM +0100, John Garry wrote:
> On 01/07/2025 19:08, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Allow callers of mkfs.xfs to specify a desired maximum atomic write
> > size.  This value will cause the log size to be adjusted to support
> > software atomic writes, and the AG size to be aligned to support
> > hardware atomic writes.
> > 
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> 
> thanks, regardless of comments below, FWIW:
> 
> Reviewed-by: John Garry <john.g.garry@oracle.com>
> 
> >   		goto validate;
> > @@ -4971,6 +4998,140 @@ calc_concurrency_logblocks(
> >   	return logblocks;
> >   }
> > +#define MAX_RW_COUNT (INT_MAX & ~(getpagesize() - 1))
> > +
> > +/* Maximum atomic write IO size that the kernel allows. */
> 
> FWIW, statx atomic write unit max is a 32b value, so we get a 2GB limit just
> from that factor

<nod> But we might as well mirror the kernel's calculations...

> > +static inline xfs_extlen_t calc_atomic_write_max(struct mkfs_params *cfg)
> > +{
> > +	return rounddown_pow_of_two(MAX_RW_COUNT >> cfg->blocklog);
> > +}
> > +
> > +static inline unsigned int max_pow_of_two_factor(const unsigned int nr)
> > +{
> > +	return 1 << (ffs(nr) - 1);
> > +}
> > +
> > +/*
> > + * If the data device advertises atomic write support, limit the size of data
> > + * device atomic writes to the greatest power-of-two factor of the AG size so
> > + * that every atomic write unit aligns with the start of every AG.  This is
> > + * required so that the per-AG allocations for an atomic write will always be
> > + * aligned compatibly with the alignment requirements of the storage.
> > + *
> > + * If the data device doesn't advertise atomic writes, then there are no
> > + * alignment restrictions and the largest out-of-place write we can do
> > + * ourselves is the number of blocks that user files can allocate from any AG.
> > + */
> > +static inline xfs_extlen_t
> > +calc_perag_awu_max(
> > +	struct mkfs_params	*cfg,
> > +	struct fs_topology	*ft)
> > +{
> > +	if (ft->data.awu_min > 0)
> > +		return max_pow_of_two_factor(cfg->agsize);
> > +	return cfg->agsize;
> 
> out of curiosity, for out-of-place atomic writes, is there anything to stop
> the blocks being allocated across multiple AGs?

Nope.  But they'll at least get the software fallback, same as if they
were writing to a severely fragmented filesystem.

--D

--D