All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 04/10] xfs: remove an unsafe retry in xfs_bmbt_alloc_block
Date: Thu, 13 Apr 2017 14:30:06 -0400	[thread overview]
Message-ID: <20170413183006.GD25915@bfoster.bfoster> (raw)
In-Reply-To: <20170413080517.12564-5-hch@lst.de>

On Thu, Apr 13, 2017 at 10:05:11AM +0200, Christoph Hellwig wrote:
> We've already reserved all possible required blocks and checked
> they are avaible in the same AG.
> 

I'm not quite following why this retry is unsafe as noted in the patch
title.. do you mean "unnecessary?" AFAICT, the firstblock == NULLFSBLOCK
case means we can issue this first allocation from any AG. If no AG can
allocate a block while satisfying minleft, then we can still safely
allocate from any AG provided any subsequent allocations occur in
increasing AG order (i.e., by setting dop_low), right?

Also, if this is unnecessary, what exactly verifies that all of the
reserved blocks are available within the same AG?

This patch may ultimately be fine, but at minimum I think a bit more
context/explanation is needed in the commit log. A couple things that
give me pause are 1.) this is a context highly sensitive to allocation
failure and 2.) the minleft used in the initial allocation is based on
the transaction block reservation, which isn't exactly deterministic (so
can some future transaction now increase the likelihood of bmbt block
allocation failure because it decided to reserve too many extra
blocks?).

Brian

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>  fs/xfs/libxfs/xfs_bmap_btree.c | 13 -------------
>  1 file changed, 13 deletions(-)
> 
> diff --git a/fs/xfs/libxfs/xfs_bmap_btree.c b/fs/xfs/libxfs/xfs_bmap_btree.c
> index 3e17ceda038c..ce41dd5fbb34 100644
> --- a/fs/xfs/libxfs/xfs_bmap_btree.c
> +++ b/fs/xfs/libxfs/xfs_bmap_btree.c
> @@ -476,19 +476,6 @@ xfs_bmbt_alloc_block(
>  	if (error)
>  		goto error0;
>  
> -	if (args.fsbno == NULLFSBLOCK && args.minleft) {
> -		/*
> -		 * Could not find an AG with enough free space to satisfy
> -		 * a full btree split.  Try again and if
> -		 * successful activate the lowspace algorithm.
> -		 */
> -		args.fsbno = 0;
> -		args.type = XFS_ALLOCTYPE_FIRST_AG;
> -		error = xfs_alloc_vextent(&args);
> -		if (error)
> -			goto error0;
> -		cur->bc_private.b.dfops->dop_low = true;
> -	}
>  	if (WARN_ON_ONCE(args.fsbno == NULLFSBLOCK)) {
>  		XFS_BTREE_TRACE_CURSOR(cur, XBT_EXIT);
>  		*stat = 0;
> -- 
> 2.11.0
> 
> --
> 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

  reply	other threads:[~2017-04-13 18:30 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13  8:05 fix space reservations underneath xfs_bmapi_write Christoph Hellwig
2017-04-13  8:05 ` [PATCH 01/10] xfs: introduce xfs_trans_blk_res Christoph Hellwig
2017-04-13 18:28   ` Brian Foster
2017-04-13  8:05 ` [PATCH 02/10] xfs: rewrite xfs_da_grow_inode_int Christoph Hellwig
2017-04-13 18:28   ` Brian Foster
2017-04-13  8:05 ` [PATCH 03/10] xfs: remove the XFS_BMAPI_CONTIG flag Christoph Hellwig
2017-04-13 18:28   ` Brian Foster
2017-04-13  8:05 ` [PATCH 04/10] xfs: remove an unsafe retry in xfs_bmbt_alloc_block Christoph Hellwig
2017-04-13 18:30   ` Brian Foster [this message]
2017-04-14  7:46     ` Christoph Hellwig
2017-04-17 14:19       ` Brian Foster
2017-04-18  7:54         ` Christoph Hellwig
2017-04-18 14:18           ` Brian Foster
2017-04-25  7:30             ` Christoph Hellwig
2017-04-25 12:11               ` Brian Foster
2017-04-13  8:05 ` [PATCH 05/10] xfs: remove the total argument to xfs_bmap_local_to_extents Christoph Hellwig
2017-04-17 14:19   ` Brian Foster
2017-04-13  8:05 ` [PATCH 06/10] xfs: fix bmap minleft calculation Christoph Hellwig
2017-04-17 14:19   ` Brian Foster
2017-04-18  7:59     ` Christoph Hellwig
2017-04-13  8:05 ` [PATCH 07/10] xfs: fix space reservation in xfs_bmbt_alloc_block Christoph Hellwig
2017-04-17 14:19   ` Brian Foster
2017-04-13  8:05 ` [PATCH 08/10] xfs: introduce a XFS_BMAPI_BESTEFFORT flag Christoph Hellwig
2017-04-17 18:08   ` Brian Foster
2017-04-18  7:58     ` Christoph Hellwig
2017-04-18 14:18       ` Brian Foster
2017-04-13  8:05 ` [PATCH 09/10] xfs: kill the dop_low flag Christoph Hellwig
2017-04-17 18:08   ` Brian Foster
2017-04-13  8:05 ` [PATCH 10/10] xfs: remove xfs_bmap_alloc Christoph Hellwig
2017-04-17 18:08   ` Brian Foster

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=20170413183006.GD25915@bfoster.bfoster \
    --to=bfoster@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.