From: Brian Foster <bfoster@redhat.com>
To: linux-xfs@vger.kernel.org
Cc: djwong@kernel.org, sandeen@sandeen.net
Subject: [PATCH] xfsprogs/mkfs: prototype XFS image mode format for scalable AG growth
Date: Tue, 8 Oct 2024 09:25:56 -0400 [thread overview]
Message-ID: <20241008132556.81878-1-bfoster@redhat.com> (raw)
In-Reply-To: <20241008131348.81013-1-bfoster@redhat.com>
Tweak a few checks to facilitate experimentation with an agcount=1
filesystem format with a larger agsize than the filesystem data
size. The purpose of this is to POC a filesystem image mode format
for XFS that better supports the typical cloud filesystem image
deployment use case where a very small fs image is created and then
immediately grown orders of magnitude in size once deployed to
container environments. The large grow size delta produces
filesystems with excessive AG counts, which leads to various other
functional problems that eventually derive from this sort of
pathological geometry.
To experiment with this patch, format a small fs with something like
the following:
mkfs.xfs -f -lsize=64m -dsize=512m,agcount=1,agsize=8g <imgfile>
Increase the underlying image file size, mount and grow. The
filesystem will grow according to the format time AG size as if the
AG was a typical runt AG on a traditional multi-AG fs.
This means that the filesystem remains with an AG count of 1 until
fs size grows beyond AG size. Since the typical deployment workflow
is an immediate very small -> very large, one-time grow, the image
fs can set a reasonable enough default or configurable AG size
(based on user input) that ensures deployed filesystems end up in a
generally supportable geometry (i.e. with multiple AGs for
superblock redundancy) before seeing production workloads.
Further optional changes are possible on the kernel side to help
provide some simple guardrails against misuse of this mechanism. For
example, the kernel could do anything from warn/fail or restrict
runtime functionality for an insufficient grow. The image mode
itself could set a backwards incompat feature bit that requires a
mount option to enable full functionality (with the exception of
growfs). More discussion is required to determine whether this
provides a usable solution for the common cloud workflows that
exhibit this problem and what the right interface and/or limitations
are to ensure it is used correctly.
Not-Signed-off-by: Brian Foster <bfoster@redhat.com>
---
This is mostly a repost of the previous RFD patch to allow mkfs to
create single AG filesystems with AG sizes larger than the filesystem
itself. The main tweak in this version is that agcount=1 is allowed not
just for explicitly outsized AG sizes, but for any file-based target
device. This supports either setting a large AG size at format time or
sticking with the default size and letting the kernel set a new AG size
at growfs time.
Brian
mkfs/xfs_mkfs.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index bbd0dbb6c..20168b58d 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -329,8 +329,7 @@ static struct opt_params dopts = {
},
.subopt_params = {
{ .index = D_AGCOUNT,
- .conflicts = { { &dopts, D_AGSIZE },
- { &dopts, D_CONCURRENCY },
+ .conflicts = { { &dopts, D_CONCURRENCY },
{ NULL, LAST_CONFLICT } },
.minval = 1,
.maxval = XFS_MAX_AGNUMBER,
@@ -372,8 +371,7 @@ static struct opt_params dopts = {
.defaultval = SUBOPT_NEEDS_VAL,
},
{ .index = D_AGSIZE,
- .conflicts = { { &dopts, D_AGCOUNT },
- { &dopts, D_CONCURRENCY },
+ .conflicts = { { &dopts, D_CONCURRENCY },
{ NULL, LAST_CONFLICT } },
.convert = true,
.minval = XFS_AG_MIN_BYTES,
@@ -1264,7 +1262,7 @@ validate_ag_geometry(
usage();
}
- if (agsize > dblocks) {
+ if (agsize > dblocks && agcount != 1) {
fprintf(stderr,
_("agsize (%lld blocks) too big, data area is %lld blocks\n"),
(long long)agsize, (long long)dblocks);
@@ -2812,12 +2810,20 @@ validate_supported(
/*
* Filesystems should not have fewer than two AGs, because we need to
- * have redundant superblocks.
+ * have redundant superblocks. The exception is filesystem image files
+ * that are intended to be grown on deployment before production use.
+ *
+ * A single AG provides more flexibility to grow the filesystem because
+ * the AG size can be grown until a second AG is added. This helps
+ * prevent tiny image filesystems being grown to unwieldy AG counts.
*/
if (mp->m_sb.sb_agcount < 2) {
fprintf(stderr,
- _("Filesystem must have at least 2 superblocks for redundancy!\n"));
- usage();
+ _("Filesystem must have at least 2 superblocks for redundancy.\n"));
+ if (!cli->xi->data.isfile)
+ usage();
+ fprintf(stderr,
+ _("Proceeding for image file, grow before use.\n"));
}
}
--
2.46.2
prev parent reply other threads:[~2024-10-08 13:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 13:13 [RFC 0/4] xfs: prototype dynamic AG size grow for image mode Brian Foster
2024-10-08 13:13 ` [RFC 1/4] xfs: factor out sb_agblocks usage in growfs Brian Foster
2024-10-08 13:13 ` [RFC 2/4] xfs: transaction support for sb_agblocks updates Brian Foster
2024-10-09 8:05 ` Christoph Hellwig
2024-10-09 12:38 ` Brian Foster
2024-10-09 12:44 ` Christoph Hellwig
2024-10-08 13:13 ` [RFC 3/4] xfs: factor out a helper to calculate post-growfs agcount Brian Foster
2024-10-08 13:13 ` [RFC 4/4] xfs: support dynamic AG size growing on single AG filesystems Brian Foster
2024-10-08 13:25 ` Brian Foster [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241008132556.81878-1-bfoster@redhat.com \
--to=bfoster@redhat.com \
--cc=djwong@kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox