Re: [RFE] xfs_growfs: option to clamp growth to an AG boundary

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

On Tue, Feb 24, 2026 at 11:44:01AM -0800, Darrick J. Wong wrote:
> On Tue, Feb 24, 2026 at 07:01:11AM -0800, Christoph Hellwig wrote:
> > On Mon, Feb 23, 2026 at 03:08:40PM -0800, Darrick J. Wong wrote:
> > > On Tue, Feb 24, 2026 at 12:29:49AM +0500, Марк Коренберг wrote:
> > > > ```
> > > > cp: failed to clone
> > > > '/run/ideco-overlay-dir/ideco-trash-o4ut52ue/upperdir/var/lib/clickhouse/store/e2b/e2bdef56-6be8-40bf-8fab-d8fb2e9fdd94/90-20250905_11925_11925_0/primary.cidx'
> > > > from '/run/ideco-overlay-dir/storage/ideco-ngfw-19-7-19/upperdir/var/lib/clickhouse/store/e2b/e2bdef56-6be8-40bf-8fab-d8fb2e9fdd94/90-20250905_11925_11925_0/primary.cidx':
> > > > No space left on device
> > > 
> > > Ah, that.  coreutils seems to think that FICLONE returning ENOSPC is a
> > > fatal error.  I wonder if we need to amend the ficlone manpage to state
> > > that ENOSPC can happen if there's not enough space in an AG to clone and
> > > that the caller might try a regular copy; or just change xfs to return a
> > > different errno?
> > 
> > I think the problem is that we report ENOSPC for this.  The historic
> > error code coming from the old btrfs days is EINVAL for "can't support
> > this for random unlisted reason", which btrfs does for example for
> > inline extents.  We really should turn ENOSPC into that.
> 
> Yeah, I'll give that a spin.

...and that regresses generic/33[34] because they actually fill the
filesystem up to full (or at least to the point where the fs won't let
us write more) and test that reflink returns ENOSPC.

Seeing as the reporter would actually rather we didn't fall back to a
slow pagecache copy(!) I'll drop this patch.

--D