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@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
>
> thanks, regardless of comments below, FWIW:
>
> Reviewed-by: John Garry <john.g.garry@xxxxxxxxxx>
>
> > 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
