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

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

[Марк Коренберг]

Hi,

I ran into an issue after growing an XFS filesystem where the final
allocation group (last AG) ended up very small. Most workloads were
fine, but large reflink-heavy copies started failing. In my case,
copying a ClickHouse data directory with:

`cp -a --reflink=always ...`

fails on a filesystem with a tiny last AG. Using --reflink=auto
doesn’t help either, because `cp` doesn’t fall back to a non-reflink
copy if the reflink attempt fails.

To work around this, I had to write scripts that compute a “safe”
target size before running xfs_growfs. The alignment I needed is a bit
awkward:

1. Round the LV size up to the next multiple of the filesystem AG
size, so the grown filesystem ends exactly on an AG boundary (no
partial/tiny last AG).

2. Then round the LV size down to the LVM extents size (4 MiB in my
case). Rounding up to the LVM granularity can reintroduce a tiny last
AG.
If the automatically chosen AG size were aligned to that granularity,
step (2) wouldn’t be necessary.

This feels like something xfsprogs could support directly. My proposals:

1. xfs_growfs: add an option to print an “optimal grow target size”:
the current(new) block device size rounded **down** to a multiple of
the AG size.
A --json output mode would make this easy to consume from scripts.

2. AG size calculation/alignment: when choosing an automatic AG size,
always round it down to an alignment such as 4 MiB, or (preferably)
consider the underlying device/LVM extent size when it can be
detected, instead of using a constant.

3. Docs (mkfs + AG sizing): when specifying AG size manually,
recommend: choosing filesystem sizing so the final size is an integer
multiple of AG size (i.e., no partial last AG), and aligning the AG
size to the underlying allocation granularity (e.g., LVM
extent/segment size) when applicable.

4. Docs (xfs_growfs): add a note that it’s highly preferable to grow
the filesystem in multiples of the existing AG size, to avoid a tiny
last AG.

5. Optional grow mode: add a xfs_growfs mode/switch that grows “as
much as possible”, but clamps the resulting filesystem size **down**
to an AG boundary, and reports how much space is left unused (e.g., “X
bytes left unallocated to avoid a partial final AG”).

This might sound like a corner case, but it’s easy to hit in practice
when the block device is resized to just arbitrary chosen size then
xfs_growfs expands to consume the whole device.

Thanks,
Mark

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

[Darrick J. Wong]

On Mon, Feb 23, 2026 at 02:48:48PM +0500, Марк Коренберг wrote:
> Hi,
> 
> I ran into an issue after growing an XFS filesystem where the final
> allocation group (last AG) ended up very small. Most workloads were
> fine, but large reflink-heavy copies started failing. In my case,
> copying a ClickHouse data directory with:
> 
> `cp -a --reflink=always ...`
> 
> fails on a filesystem with a tiny last AG. Using --reflink=auto

How does it fail?

--D

> doesn’t help either, because `cp` doesn’t fall back to a non-reflink
> copy if the reflink attempt fails.
> 
> To work around this, I had to write scripts that compute a “safe”
> target size before running xfs_growfs. The alignment I needed is a bit
> awkward:
> 
> 1. Round the LV size up to the next multiple of the filesystem AG
> size, so the grown filesystem ends exactly on an AG boundary (no
> partial/tiny last AG).
> 
> 2. Then round the LV size down to the LVM extents size (4 MiB in my
> case). Rounding up to the LVM granularity can reintroduce a tiny last
> AG.
> If the automatically chosen AG size were aligned to that granularity,
> step (2) wouldn’t be necessary.
> 
> This feels like something xfsprogs could support directly. My proposals:
> 
> 1. xfs_growfs: add an option to print an “optimal grow target size”:
> the current(new) block device size rounded **down** to a multiple of
> the AG size.
> A --json output mode would make this easy to consume from scripts.
> 
> 2. AG size calculation/alignment: when choosing an automatic AG size,
> always round it down to an alignment such as 4 MiB, or (preferably)
> consider the underlying device/LVM extent size when it can be
> detected, instead of using a constant.
> 
> 3. Docs (mkfs + AG sizing): when specifying AG size manually,
> recommend: choosing filesystem sizing so the final size is an integer
> multiple of AG size (i.e., no partial last AG), and aligning the AG
> size to the underlying allocation granularity (e.g., LVM
> extent/segment size) when applicable.
> 
> 4. Docs (xfs_growfs): add a note that it’s highly preferable to grow
> the filesystem in multiples of the existing AG size, to avoid a tiny
> last AG.
> 
> 5. Optional grow mode: add a xfs_growfs mode/switch that grows “as
> much as possible”, but clamps the resulting filesystem size **down**
> to an AG boundary, and reports how much space is left unused (e.g., “X
> bytes left unallocated to avoid a partial final AG”).
> 
> This might sound like a corner case, but it’s easy to hit in practice
> when the block device is resized to just arbitrary chosen size then
> xfs_growfs expands to consume the whole device.
> 
> Thanks,
> Mark
> 

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

[Марк Коренберг]

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

In all such cases `xfs_bmap -v  ......` always refer to the last AG.

# xfs_spaceman -c 'freesp -g' /run/ideco-overlay-dir
        AG    extents     blocks
         0        461    6658463
         1         98    6406298
        .......
        15        125    6638281
        16          1          1   <====== (!)

пн, 23 февр. 2026 г. в 21:23, Darrick J. Wong <djwong@kernel.org>:
>
> On Mon, Feb 23, 2026 at 02:48:48PM +0500, Марк Коренберг wrote:
> > Hi,
> >
> > I ran into an issue after growing an XFS filesystem where the final
> > allocation group (last AG) ended up very small. Most workloads were
> > fine, but large reflink-heavy copies started failing. In my case,
> > copying a ClickHouse data directory with:
> >
> > `cp -a --reflink=always ...`
> >
> > fails on a filesystem with a tiny last AG. Using --reflink=auto
>
> How does it fail?
>
> --D
>
> > doesn’t help either, because `cp` doesn’t fall back to a non-reflink
> > copy if the reflink attempt fails.
> >
> > To work around this, I had to write scripts that compute a “safe”
> > target size before running xfs_growfs. The alignment I needed is a bit
> > awkward:
> >
> > 1. Round the LV size up to the next multiple of the filesystem AG
> > size, so the grown filesystem ends exactly on an AG boundary (no
> > partial/tiny last AG).
> >
> > 2. Then round the LV size down to the LVM extents size (4 MiB in my
> > case). Rounding up to the LVM granularity can reintroduce a tiny last
> > AG.
> > If the automatically chosen AG size were aligned to that granularity,
> > step (2) wouldn’t be necessary.
> >
> > This feels like something xfsprogs could support directly. My proposals:
> >
> > 1. xfs_growfs: add an option to print an “optimal grow target size”:
> > the current(new) block device size rounded **down** to a multiple of
> > the AG size.
> > A --json output mode would make this easy to consume from scripts.
> >
> > 2. AG size calculation/alignment: when choosing an automatic AG size,
> > always round it down to an alignment such as 4 MiB, or (preferably)
> > consider the underlying device/LVM extent size when it can be
> > detected, instead of using a constant.
> >
> > 3. Docs (mkfs + AG sizing): when specifying AG size manually,
> > recommend: choosing filesystem sizing so the final size is an integer
> > multiple of AG size (i.e., no partial last AG), and aligning the AG
> > size to the underlying allocation granularity (e.g., LVM
> > extent/segment size) when applicable.
> >
> > 4. Docs (xfs_growfs): add a note that it’s highly preferable to grow
> > the filesystem in multiples of the existing AG size, to avoid a tiny
> > last AG.
> >
> > 5. Optional grow mode: add a xfs_growfs mode/switch that grows “as
> > much as possible”, but clamps the resulting filesystem size **down**
> > to an AG boundary, and reports how much space is left unused (e.g., “X
> > bytes left unallocated to avoid a partial final AG”).
> >
> > This might sound like a corner case, but it’s easy to hit in practice
> > when the block device is resized to just arbitrary chosen size then
> > xfs_growfs expands to consume the whole device.
> >
> > Thanks,
> > Mark
> >



-- 
Segmentation fault

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

[Darrick J. Wong]

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?

--D

> ```
> 
> In all such cases `xfs_bmap -v  ......` always refer to the last AG.
> 
> # xfs_spaceman -c 'freesp -g' /run/ideco-overlay-dir
>         AG    extents     blocks
>          0        461    6658463
>          1         98    6406298
>         .......
>         15        125    6638281
>         16          1          1   <====== (!)
> 
> пн, 23 февр. 2026 г. в 21:23, Darrick J. Wong <djwong@kernel.org>:
> >
> > On Mon, Feb 23, 2026 at 02:48:48PM +0500, Марк Коренберг wrote:
> > > Hi,
> > >
> > > I ran into an issue after growing an XFS filesystem where the final
> > > allocation group (last AG) ended up very small. Most workloads were
> > > fine, but large reflink-heavy copies started failing. In my case,
> > > copying a ClickHouse data directory with:
> > >
> > > `cp -a --reflink=always ...`
> > >
> > > fails on a filesystem with a tiny last AG. Using --reflink=auto
> >
> > How does it fail?
> >
> > --D
> >
> > > doesn’t help either, because `cp` doesn’t fall back to a non-reflink
> > > copy if the reflink attempt fails.
> > >
> > > To work around this, I had to write scripts that compute a “safe”
> > > target size before running xfs_growfs. The alignment I needed is a bit
> > > awkward:
> > >
> > > 1. Round the LV size up to the next multiple of the filesystem AG
> > > size, so the grown filesystem ends exactly on an AG boundary (no
> > > partial/tiny last AG).
> > >
> > > 2. Then round the LV size down to the LVM extents size (4 MiB in my
> > > case). Rounding up to the LVM granularity can reintroduce a tiny last
> > > AG.
> > > If the automatically chosen AG size were aligned to that granularity,
> > > step (2) wouldn’t be necessary.
> > >
> > > This feels like something xfsprogs could support directly. My proposals:
> > >
> > > 1. xfs_growfs: add an option to print an “optimal grow target size”:
> > > the current(new) block device size rounded **down** to a multiple of
> > > the AG size.
> > > A --json output mode would make this easy to consume from scripts.
> > >
> > > 2. AG size calculation/alignment: when choosing an automatic AG size,
> > > always round it down to an alignment such as 4 MiB, or (preferably)
> > > consider the underlying device/LVM extent size when it can be
> > > detected, instead of using a constant.
> > >
> > > 3. Docs (mkfs + AG sizing): when specifying AG size manually,
> > > recommend: choosing filesystem sizing so the final size is an integer
> > > multiple of AG size (i.e., no partial last AG), and aligning the AG
> > > size to the underlying allocation granularity (e.g., LVM
> > > extent/segment size) when applicable.
> > >
> > > 4. Docs (xfs_growfs): add a note that it’s highly preferable to grow
> > > the filesystem in multiples of the existing AG size, to avoid a tiny
> > > last AG.
> > >
> > > 5. Optional grow mode: add a xfs_growfs mode/switch that grows “as
> > > much as possible”, but clamps the resulting filesystem size **down**
> > > to an AG boundary, and reports how much space is left unused (e.g., “X
> > > bytes left unallocated to avoid a partial final AG”).
> > >
> > > This might sound like a corner case, but it’s easy to hit in practice
> > > when the block device is resized to just arbitrary chosen size then
> > > xfs_growfs expands to consume the whole device.
> > >
> > > Thanks,
> > > Mark
> > >
> 
> 
> 
> -- 
> Segmentation fault
> 

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

[Марк Коренберг]

вт, 24 февр. 2026 г. в 04:08, Darrick J. Wong <djwong@kernel.org>:
>
> 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?

Possibly. But in my use case, though, I need fast copying without
additional disk-space consumption, so reflinks are important. I’d
rather tolerate reduced free space than lose reflink capability.


>
> --D
>
> > ```
> >
> > In all such cases `xfs_bmap -v  ......` always refer to the last AG.
> >
> > # xfs_spaceman -c 'freesp -g' /run/ideco-overlay-dir
> >         AG    extents     blocks
> >          0        461    6658463
> >          1         98    6406298
> >         .......
> >         15        125    6638281
> >         16          1          1   <====== (!)
> >
> > пн, 23 февр. 2026 г. в 21:23, Darrick J. Wong <djwong@kernel.org>:
> > >
> > > On Mon, Feb 23, 2026 at 02:48:48PM +0500, Марк Коренберг wrote:
> > > > Hi,
> > > >
> > > > I ran into an issue after growing an XFS filesystem where the final
> > > > allocation group (last AG) ended up very small. Most workloads were
> > > > fine, but large reflink-heavy copies started failing. In my case,
> > > > copying a ClickHouse data directory with:
> > > >
> > > > `cp -a --reflink=always ...`
> > > >
> > > > fails on a filesystem with a tiny last AG. Using --reflink=auto
> > >
> > > How does it fail?
> > >
> > > --D
> > >
> > > > doesn’t help either, because `cp` doesn’t fall back to a non-reflink
> > > > copy if the reflink attempt fails.
> > > >
> > > > To work around this, I had to write scripts that compute a “safe”
> > > > target size before running xfs_growfs. The alignment I needed is a bit
> > > > awkward:
> > > >
> > > > 1. Round the LV size up to the next multiple of the filesystem AG
> > > > size, so the grown filesystem ends exactly on an AG boundary (no
> > > > partial/tiny last AG).
> > > >
> > > > 2. Then round the LV size down to the LVM extents size (4 MiB in my
> > > > case). Rounding up to the LVM granularity can reintroduce a tiny last
> > > > AG.
> > > > If the automatically chosen AG size were aligned to that granularity,
> > > > step (2) wouldn’t be necessary.
> > > >
> > > > This feels like something xfsprogs could support directly. My proposals:
> > > >
> > > > 1. xfs_growfs: add an option to print an “optimal grow target size”:
> > > > the current(new) block device size rounded **down** to a multiple of
> > > > the AG size.
> > > > A --json output mode would make this easy to consume from scripts.
> > > >
> > > > 2. AG size calculation/alignment: when choosing an automatic AG size,
> > > > always round it down to an alignment such as 4 MiB, or (preferably)
> > > > consider the underlying device/LVM extent size when it can be
> > > > detected, instead of using a constant.
> > > >
> > > > 3. Docs (mkfs + AG sizing): when specifying AG size manually,
> > > > recommend: choosing filesystem sizing so the final size is an integer
> > > > multiple of AG size (i.e., no partial last AG), and aligning the AG
> > > > size to the underlying allocation granularity (e.g., LVM
> > > > extent/segment size) when applicable.
> > > >
> > > > 4. Docs (xfs_growfs): add a note that it’s highly preferable to grow
> > > > the filesystem in multiples of the existing AG size, to avoid a tiny
> > > > last AG.
> > > >
> > > > 5. Optional grow mode: add a xfs_growfs mode/switch that grows “as
> > > > much as possible”, but clamps the resulting filesystem size **down**
> > > > to an AG boundary, and reports how much space is left unused (e.g., “X
> > > > bytes left unallocated to avoid a partial final AG”).
> > > >
> > > > This might sound like a corner case, but it’s easy to hit in practice
> > > > when the block device is resized to just arbitrary chosen size then
> > > > xfs_growfs expands to consume the whole device.
> > > >
> > > > Thanks,
> > > > Mark
> > > >
> >
> >
> >
> > --
> > Segmentation fault
> >



-- 
Segmentation fault

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

[Christoph Hellwig]

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.

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

[Darrick J. Wong]

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.

--D

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

[Darrick J. Wong]

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

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

[Christoph Hellwig]

On Tue, Feb 24, 2026 at 02:25:51PM -0800, Darrick J. Wong wrote:
> > 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.

Not sure if the reported wanted it, but randomly failing reflink with
ENOSPC on a file system that is not out of space is really, really
weird behavior, and I think we should fix it.

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

[Christoph Hellwig]

On Mon, Feb 23, 2026 at 02:48:48PM +0500, Марк Коренберг wrote:
> This feels like something xfsprogs could support directly. My proposals:

I like your proposal.  This is actually a relatively east project,
and I've happy to mentor whomever wants to take it up.  Although
I think json output while generally useful is probably a separate
issue and should be addressed separately and in a more general
fashion.

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

[Darrick J. Wong]

On Tue, Feb 24, 2026 at 07:02:32AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 23, 2026 at 02:48:48PM +0500, Марк Коренберг wrote:
> > This feels like something xfsprogs could support directly. My proposals:
> 
> I like your proposal.  This is actually a relatively east project,
> and I've happy to mentor whomever wants to take it up.  Although
> I think json output while generally useful is probably a separate
> issue and should be addressed separately and in a more general
> fashion.

I've long thought it might be useful to have an xfs_db command that
could spit out a mkfs config file for a given filesystem, so you could
just do:

# xfs_db -c 'mkfs_config' /dev/sda1 > /tmp/foo.cfg
# mkfs.xfs -c /tmp/foo.cfg -f /dev/sdb1

and then sdb1 gets whatever featureset sda1 had.  The reason I never
pursued this is that I don't know how much we'd really want to preserve.
User-visible features, yes.  But what about geometry things like group
size, volume size, or RAID stripe parameters?

--D

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

[Lukas Herbolt]

> I like your proposal.  This is actually a relatively east project,
> and I've happy to mentor whomever wants to take it up.  Although
I like the idea and can take a look at it, but I will leave it to
the author if they will pick it up.

Just for the LVM extent size, LVM does not expose it unless you look
at the metadata, afaik.

> I think json output while generally useful is probably a separate
> issue and should be addressed separately and in a more general
> fashion.

I guess json output could be also added to mkfs.xfs, xfs_admin (xfs_db)


-- 
-lhe