From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org, eguan@redhat.com, darrick.wong@oracle.com
Subject: Re: [PATCH 3/5] xfs: fix bogus minleft manipulations
Date: Wed, 4 Jan 2017 13:19:33 -0500 [thread overview]
Message-ID: <20170104181933.GC41989@bfoster.bfoster> (raw)
In-Reply-To: <1482436822-31546-4-git-send-email-hch@lst.de>
On Thu, Dec 22, 2016 at 09:00:20PM +0100, Christoph Hellwig wrote:
> We can't just set minleft to 0 when we're low on space - that's exactly
> what we need minleft for: to protect space in the AG for btree block
> allocations when we are low on free space.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
Staring at this some more, I'm still not terribly fond of this, moreso
because I wonder how much more of this can be ripped out and whether the
low space allocator thing is still effective. Aside from that, afaict
the set_aside change should make it robust and addresses my previous
question in that it holds blocks out of all transaction reservations.
I'm also curious whether the set_aside patch alone addresses the
original problem, or setting minleft = 0 in one of these cases was
actually the cause.
> fs/xfs/libxfs/xfs_alloc.c | 24 +++++++-----------------
> fs/xfs/libxfs/xfs_bmap.c | 3 ---
> fs/xfs/libxfs/xfs_bmap_btree.c | 14 --------------
> 3 files changed, 7 insertions(+), 34 deletions(-)
>
...
> diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> index 19c05e9..62663a2 100644
> --- a/fs/xfs/libxfs/xfs_bmap.c
> +++ b/fs/xfs/libxfs/xfs_bmap.c
> @@ -3812,7 +3812,6 @@ xfs_bmap_btalloc(
> args.fsbno = 0;
> args.type = XFS_ALLOCTYPE_FIRST_AG;
> args.total = ap->minlen;
> - args.minleft = 0;
> if ((error = xfs_alloc_vextent(&args)))
> return error;
> ap->dfops->dop_low = true;
...
> diff --git a/fs/xfs/libxfs/xfs_bmap_btree.c b/fs/xfs/libxfs/xfs_bmap_btree.c
> index d6330c2..9581ee8 100644
> --- a/fs/xfs/libxfs/xfs_bmap_btree.c
> +++ b/fs/xfs/libxfs/xfs_bmap_btree.c
> @@ -499,20 +499,6 @@ xfs_bmbt_alloc_block(
> goto try_another_ag;
> }
>
> - if (args.fsbno == NULLFSBLOCK && args.minleft) {
> - /*
> - * Could not find an AG with enough free space to satisfy
> - * a full btree split. Try again without minleft and if
> - * successful activate the lowspace algorithm.
> - */
> - args.fsbno = 0;
> - args.type = XFS_ALLOCTYPE_FIRST_AG;
> - args.minleft = 0;
> - error = xfs_alloc_vextent(&args);
> - if (error)
> - goto error0;
> - cur->bc_private.b.dfops->dop_low = true;
> - }
We have a similar retry pattern in xfs_bmap_btalloc() where, in the hunk
just above, we retain the retry that appears analogous to this one (in
that it activates the low space algo) and just drop the minleft = 0 bit.
Here we are dropping the whole thing. Any reason not to be consistent
one way or the other? (Though do note that we don't check firstblock
here...).
Brian
> if (args.fsbno == NULLFSBLOCK) {
> XFS_BTREE_TRACE_CURSOR(cur, XBT_EXIT);
> *stat = 0;
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-01-04 18:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-22 20:00 minleft fixes V2 Christoph Hellwig
2016-12-22 20:00 ` [PATCH 1/5] xfs: bump up reserved blocks in xfs_alloc_set_aside Christoph Hellwig
2017-01-04 14:33 ` Brian Foster
2017-01-08 10:30 ` Christoph Hellwig
2017-01-08 16:07 ` Brian Foster
2016-12-22 20:00 ` [PATCH 2/5] xfs: fix the alignment fallback in xfs_bmap_btalloc Christoph Hellwig
2017-01-04 14:34 ` Brian Foster
2017-01-08 10:31 ` Christoph Hellwig
2017-01-08 16:08 ` Brian Foster
2016-12-22 20:00 ` [PATCH 3/5] xfs: fix bogus minleft manipulations Christoph Hellwig
2017-01-04 18:19 ` Brian Foster [this message]
2017-01-08 10:36 ` Christoph Hellwig
2017-01-08 16:09 ` Brian Foster
2017-01-09 17:56 ` Christoph Hellwig
2016-12-22 20:00 ` [PATCH 4/5] xfs: adjust allocation length in xfs_alloc_space_available Christoph Hellwig
2017-01-04 18:19 ` Brian Foster
2016-12-22 20:00 ` [PATCH 5/5] xfs: don't rely on ->total " Christoph Hellwig
2017-01-04 18:19 ` Brian Foster
2017-01-05 1:21 ` minleft fixes V2 Eryu Guan
2017-01-05 2:01 ` Darrick J. Wong
2017-01-08 10:36 ` Christoph Hellwig
2017-01-08 16:10 ` Brian Foster
2017-01-08 18:10 ` Darrick J. Wong
2017-01-09 15:22 ` Brian Foster
2017-01-09 15:34 ` Christoph Hellwig
2017-01-09 15:43 ` Brian Foster
2017-01-10 4:23 ` 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=20170104181933.GC41989@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=eguan@redhat.com \
--cc=hch@lst.de \
--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.