All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: sandeen@sandeen.net, djwong@kernel.org
Cc: linux-xfs@vger.kernel.org, allison.henderson@oracle.com
Subject: [PATCH 2/5] mkfs: don't let internal logs consume more than 95% of an AG
Date: Tue, 15 Mar 2022 16:23:33 -0700	[thread overview]
Message-ID: <164738661360.3191861.16773208450465120679.stgit@magnolia> (raw)
In-Reply-To: <164738660248.3191861.2400129607830047696.stgit@magnolia>

From: Darrick J. Wong <djwong@kernel.org>

Currently, we don't let an internal log consume every last block in an
AG.  According to the comment, we're doing this to avoid tripping AGF
verifiers if freeblks==0, but on a modern filesystem this isn't
sufficient to avoid problems.  First, the per-AG reservations for
reflink and rmap claim up to about 1.7% of each AG for btree expansion,
and secondly, we need to have enough space in the AG to allocate the
root inode chunk, if it should be the case that the log ends up in AG 0.
We don't care about nonredundant (i.e. agcount==1) filesystems, but it
can also happen if the user passes in -lagnum=0.

Change this constraint so that we can't leave less than 5% free space
after allocating the log.  This is perhaps a bit much, but as we're
about to disallow tiny filesystems anyway, it seems unlikely to cause
problems with scenarios that we care about.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 mkfs/xfs_mkfs.c |   17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)


diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index b97bd360..ad776492 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -3271,15 +3271,18 @@ clamp_internal_log_size(
 	/*
 	 * Make sure the log fits wholly within an AG
 	 *
-	 * XXX: If agf->freeblks ends up as 0 because the log uses all
-	 * the free space, it causes the kernel all sorts of problems
-	 * with per-ag reservations. Right now just back it off one
-	 * block, but there's a whole can of worms here that needs to be
-	 * opened to decide what is the valid maximum size of a log in
-	 * an AG.
+	 * XXX: If agf->freeblks ends up as 0 because the log uses all the free
+	 * space, it causes the kernel all sorts of problems with per-AG
+	 * reservations.  The reservations are only supposed to take 2% of the
+	 * AG, but there's a further problem that if the log ends up in AG 0,
+	 * we also need space to allocate the root directory inode chunk.
+	 *
+	 * Right now just back it off by 5%, but there's a whole can of worms
+	 * here that needs to be opened to decide what is the valid maximum
+	 * size of a log in an AG.
 	 */
 	cfg->logblocks = min(cfg->logblocks,
-			     libxfs_alloc_ag_max_usable(mp) - 1);
+			     libxfs_alloc_ag_max_usable(mp) * 95 / 100);
 
 	/* and now clamp the size to the maximum supported size */
 	cfg->logblocks = min(cfg->logblocks, XFS_MAX_LOG_BLOCKS);


  parent reply	other threads:[~2022-03-15 23:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 23:23 [PATCHSET 0/5] xfsprogs: stop allowing tiny filesystems Darrick J. Wong
2022-03-15 23:23 ` [PATCH 1/5] mkfs: hoist the internal log size clamp code Darrick J. Wong
2022-03-16 18:18   ` Eric Sandeen
2022-03-15 23:23 ` Darrick J. Wong [this message]
2022-03-16 18:50   ` [PATCH 2/5] mkfs: don't let internal logs consume more than 95% of an AG Eric Sandeen
2022-03-31  5:21     ` Eric Sandeen
2022-03-31 16:20       ` Darrick J. Wong
2022-03-15 23:23 ` [PATCH 3/5] mkfs: increase the minimum log size to 64MB when possible Darrick J. Wong
2022-03-16 19:27   ` Eric Sandeen
2022-03-25 17:48   ` Eric Sandeen
2022-03-25 22:08     ` Darrick J. Wong
2022-03-15 23:23 ` [PATCH 4/5] mkfs: stop allowing tiny filesystems Darrick J. Wong
2022-03-15 23:23 ` [PATCH 5/5] mkfs: simplify the default log size ratio computation Darrick J. Wong

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=164738661360.3191861.16773208450465120679.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=allison.henderson@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.