From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com
Subject: Re: [PATCH 2/6] xfs: actually set aside enough space to handle a bmbt split
Date: Fri, 18 Mar 2022 13:52:04 -0700 [thread overview]
Message-ID: <20220318205204.GD8224@magnolia> (raw)
In-Reply-To: <YjR4cZ47tOutXB+e@bfoster>
On Fri, Mar 18, 2022 at 08:17:53AM -0400, Brian Foster wrote:
> On Thu, Mar 17, 2022 at 02:21:06PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > The comment for xfs_alloc_set_aside indicates that we want to set aside
> > enough space to handle a bmap btree split. The code, unfortunately,
> > hardcodes this to 4.
> >
> > This is incorrect, since file bmap btrees can be taller than that:
> >
> > xfs_db> btheight bmapbt -n 4294967296 -b 512
> > bmapbt: worst case per 512-byte block: 13 records (leaf) / 13 keyptrs (node)
> > level 0: 4294967296 records, 330382100 blocks
> > level 1: 330382100 records, 25414008 blocks
> > level 2: 25414008 records, 1954924 blocks
> > level 3: 1954924 records, 150379 blocks
> > level 4: 150379 records, 11568 blocks
> > level 5: 11568 records, 890 blocks
> > level 6: 890 records, 69 blocks
> > level 7: 69 records, 6 blocks
> > level 8: 6 records, 1 block
> > 9 levels, 357913945 blocks total
> >
> > Fix this by using the actual bmap btree maxlevel value for the
> > set-aside. We subtract one because the root is always in the inode and
> > hence never splits.
> >
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> > fs/xfs/libxfs/xfs_alloc.c | 7 +++++--
> > fs/xfs/libxfs/xfs_sb.c | 2 --
> > fs/xfs/xfs_mount.c | 7 +++++++
> > 3 files changed, 12 insertions(+), 4 deletions(-)
> >
> >
> ...
> > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> > index bed73e8002a5..9336176dc706 100644
> > --- a/fs/xfs/xfs_mount.c
> > +++ b/fs/xfs/xfs_mount.c
> > @@ -652,6 +652,13 @@ xfs_mountfs(
> >
> > xfs_agbtree_compute_maxlevels(mp);
> >
> > + /*
> > + * Compute the amount of space to set aside to handle btree splits now
> > + * that we have calculated the btree maxlevels.
> > + */
>
> "... to handle btree splits near -ENOSPC ..." ?
Fixed; thanks for the review!
--D
> Otherwise LGTM:
>
> Reviewed-by: Brian Foster <bfoster@redhat.com>
>
> > + mp->m_alloc_set_aside = xfs_alloc_set_aside(mp);
> > + mp->m_ag_max_usable = xfs_alloc_ag_max_usable(mp);
> > +
> > /*
> > * Check if sb_agblocks is aligned at stripe boundary. If sb_agblocks
> > * is NOT aligned turn off m_dalign since allocator alignment is within
> >
>
next prev parent reply other threads:[~2022-03-18 20:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-17 21:20 [PATCHSET v2 0/6] xfs: fix incorrect reserve pool calculations and reporting Darrick J. Wong
2022-03-17 21:21 ` [PATCH 1/6] xfs: document the XFS_ALLOC_AGFL_RESERVE constant Darrick J. Wong
2022-03-18 12:17 ` Brian Foster
2022-03-17 21:21 ` [PATCH 2/6] xfs: actually set aside enough space to handle a bmbt split Darrick J. Wong
2022-03-18 12:17 ` Brian Foster
2022-03-18 20:52 ` Darrick J. Wong [this message]
2022-03-17 21:21 ` [PATCH 3/6] xfs: don't include bnobt blocks when reserving free block pool Darrick J. Wong
2022-03-18 12:18 ` Brian Foster
2022-03-18 21:01 ` Darrick J. Wong
2022-03-17 21:21 ` [PATCH 4/6] xfs: fix infinite loop " Darrick J. Wong
2022-03-18 12:18 ` Brian Foster
2022-03-17 21:21 ` [PATCH 5/6] xfs: don't report reserved bnobt space as available Darrick J. Wong
2022-03-18 12:19 ` Brian Foster
2022-03-18 21:19 ` Darrick J. Wong
2022-03-17 21:21 ` [PATCH 6/6] xfs: rename "alloc_set_aside" to be more descriptive Darrick J. Wong
2022-03-18 12:21 ` Brian Foster
-- strict thread matches above, loose matches on Subject: below --
2022-03-20 16:43 [PATCHSET v3 0/6] xfs: fix incorrect reserve pool calculations and reporting Darrick J. Wong
2022-03-20 16:43 ` [PATCH 2/6] xfs: actually set aside enough space to handle a bmbt split Darrick J. Wong
2022-03-23 20:48 ` Dave Chinner
2022-03-24 5:26 ` Darrick J. Wong
2022-03-24 6:00 ` Dave Chinner
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=20220318205204.GD8224@magnolia \
--to=djwong@kernel.org \
--cc=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/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.