public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@redhat.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, "Darrick J. Wong" <djwong@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@lst.de>,
	Eric Sandeen <sandeen@sandeen.net>
Subject: Re: [PATCH v8 3/5] xfs: introduce xfs_ag_shrink_space()
Date: Mon, 22 Mar 2021 20:33:28 +0800	[thread overview]
Message-ID: <20210322123328.GA2007006@xiangao.remote.csb> (raw)
In-Reply-To: <YFiM07d9DQxx4qHt@bfoster>

On Mon, Mar 22, 2021 at 08:25:55AM -0400, Brian Foster wrote:
> On Mon, Mar 22, 2021 at 08:03:10PM +0800, Gao Xiang wrote:
> > Hi Brian,
> > 
> > On Mon, Mar 22, 2021 at 07:30:03AM -0400, Brian Foster wrote:
> > > On Fri, Mar 05, 2021 at 10:57:01AM +0800, Gao Xiang wrote:
> > > > This patch introduces a helper to shrink unused space in the last AG
> > > > by fixing up the freespace btree.
> > > > 
> > > > Also make sure that the per-AG reservation works under the new AG
> > > > size. If such per-AG reservation or extent allocation fails, roll
> > > > the transaction so the new transaction could cancel without any side
> > > > effects.
> > > > 
> > > > Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
> > > > ---
> > > 
> > > Looks mostly good to me. Some nits..
> > > 
> > > >  fs/xfs/libxfs/xfs_ag.c | 111 +++++++++++++++++++++++++++++++++++++++++
> > > >  fs/xfs/libxfs/xfs_ag.h |   4 +-
> > > >  2 files changed, 114 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/xfs/libxfs/xfs_ag.c b/fs/xfs/libxfs/xfs_ag.c
> > > > index 9331f3516afa..1f6f9e70e1cb 100644
> > > > --- a/fs/xfs/libxfs/xfs_ag.c
> > > > +++ b/fs/xfs/libxfs/xfs_ag.c
> > > ...
> > > > @@ -485,6 +490,112 @@ xfs_ag_init_headers(
> > > >  	return error;
> > > >  }
> > > >  
> > > > +int
> > > > +xfs_ag_shrink_space(
> > > > +	struct xfs_mount	*mp,
> > > > +	struct xfs_trans	**tpp,
> > > > +	xfs_agnumber_t		agno,
> > > > +	xfs_extlen_t		delta)
> > > > +{
> > > > +	struct xfs_alloc_arg	args = {
> > > > +		.tp	= *tpp,
> > > > +		.mp	= mp,
> > > > +		.type	= XFS_ALLOCTYPE_THIS_BNO,
> > > > +		.minlen = delta,
> > > > +		.maxlen = delta,
> > > > +		.oinfo	= XFS_RMAP_OINFO_SKIP_UPDATE,
> > > > +		.resv	= XFS_AG_RESV_NONE,
> > > > +		.prod	= 1
> > > > +	};
> > > > +	struct xfs_buf		*agibp, *agfbp;
> > > > +	struct xfs_agi		*agi;
> > > > +	struct xfs_agf		*agf;
> > > > +	int			error, err2;
> > > > +
> > > > +	ASSERT(agno == mp->m_sb.sb_agcount - 1);
> > > > +	error = xfs_ialloc_read_agi(mp, *tpp, agno, &agibp);
> > > > +	if (error)
> > > > +		return error;
> > > > +
> > > > +	agi = agibp->b_addr;
> > > > +
> > > > +	error = xfs_alloc_read_agf(mp, *tpp, agno, 0, &agfbp);
> > > > +	if (error)
> > > > +		return error;
> > > > +
> > > > +	agf = agfbp->b_addr;
> > > > +	if (XFS_IS_CORRUPT(mp, agf->agf_length != agi->agi_length))
> > > > +		return -EFSCORRUPTED;
> > > 
> > > Is this check here for a reason? It seems a bit random, so I wonder if
> > > we should just leave the extra verification to buffer verifiers.
> > 
> > It came from Darrick's thought. I'm fine with either way, but I feel
> > confused if different conflict opinions here:
> > https://lore.kernel.org/linux-xfs/20210303181931.GB3419940@magnolia/
> > 
> 
> Darrick's comment seems to refer to the check below. I'm referring to
> the check above that agi_length and agf_length match. Are they intended
> to go together? The check above seems to preexist the one below.

Sorry, update link of this:
https://lore.kernel.org/r/20210111181753.GC1164246@magnolia/

> 
> Anyways, if so, maybe just bunch them together and add a comment:
> 
> 	/* some extra paranoid checks before we shrink the ag */
> 	if (XFS_IS_CORRUPT(...))
> 		return -EFSCORRUPTED;
> 	if (delta >= agf->agf_length)
> 		return -EVINAL; 
> 

ok, will update this.

> > > 
> > > > +
> > > > +	if (delta >= agi->agi_length)
> > > > +		return -EINVAL;
> > > > +
> > > > +	args.fsbno = XFS_AGB_TO_FSB(mp, agno,
> > > > +				    be32_to_cpu(agi->agi_length) - delta);
> > > > +
> > > > +	/* remove the preallocations before allocation and re-establish then */
> ...
> > > > diff --git a/fs/xfs/libxfs/xfs_ag.h b/fs/xfs/libxfs/xfs_ag.h
> > > > index 5166322807e7..41293ebde8da 100644
> > > > --- a/fs/xfs/libxfs/xfs_ag.h
> > > > +++ b/fs/xfs/libxfs/xfs_ag.h
> > > > @@ -24,8 +24,10 @@ struct aghdr_init_data {
> > > >  };
> > > >  
> > > >  int xfs_ag_init_headers(struct xfs_mount *mp, struct aghdr_init_data *id);
> > > > +int xfs_ag_shrink_space(struct xfs_mount *mp, struct xfs_trans **tpp,
> > > > +			xfs_agnumber_t agno, xfs_extlen_t len);
> > > >  int xfs_ag_extend_space(struct xfs_mount *mp, struct xfs_trans *tp,
> > > > -			struct aghdr_init_data *id, xfs_extlen_t len);
> > > > +			struct aghdr_init_data *id, xfs_extlen_t delta);
> > > 
> > > This looks misplaced..?
> > > 
> > > Or maybe this is trying to make the APIs consistent, but the function
> > > definition still uses len as well as the declaration for
> > > _ag_shrink_space() (while the definition of that function uses delta).
> > > 
> > > FWIW, the name delta tends to suggest a signed value to me based on our
> > > pattern of usage, whereas here it seems like these helpers always want a
> > > positive value (i.e. a length).
> > 
> > Yeah, it's just misplaced, thanks for pointing out, sorry about that.
> > `delta' name came from, `len' is confusing to Darrick.
> > https://lore.kernel.org/r/20210303182527.GC3419940@magnolia/
> > 
> 
> Fair enough. I'm not worried about the name, just pointing out some
> potential inconsistencies.

Thanks for pointing out!

Thanks,
Gao Xiang

> 
> Brian
> 
> > Thanks,
> > Gao Xiang
> > 
> > > 
> > > Brian
> > > 
> > > >  int xfs_ag_get_geometry(struct xfs_mount *mp, xfs_agnumber_t agno,
> > > >  			struct xfs_ag_geometry *ageo);
> > > >  
> > > > -- 
> > > > 2.27.0
> > > > 
> > > 
> > 
> 


  reply	other threads:[~2021-03-22 12:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  2:56 [PATCH v8 0/5] xfs: support shrinking free space in the last AG Gao Xiang
2021-03-05  2:56 ` [PATCH v8 1/5] xfs: update lazy sb counters immediately for resizefs Gao Xiang
2021-03-22 11:27   ` Brian Foster
2021-03-05  2:57 ` [PATCH v8 2/5] xfs: hoist out xfs_resizefs_init_new_ags() Gao Xiang
2021-03-22 11:28   ` Brian Foster
2021-03-22 11:53     ` Gao Xiang
2021-03-22 12:21       ` Brian Foster
2021-03-05  2:57 ` [PATCH v8 3/5] xfs: introduce xfs_ag_shrink_space() Gao Xiang
2021-03-09 18:05   ` Darrick J. Wong
2021-03-22 11:30   ` Brian Foster
2021-03-22 12:03     ` Gao Xiang
2021-03-22 12:25       ` Brian Foster
2021-03-22 12:33         ` Gao Xiang [this message]
2021-03-22 16:38           ` Darrick J. Wong
2021-03-05  2:57 ` [PATCH v8 4/5] xfs: support shrinking unused space in the last AG Gao Xiang
2021-03-22 11:30   ` Brian Foster
2021-03-22 12:07     ` Gao Xiang
2021-03-22 12:26       ` Brian Foster
2021-03-22 12:36         ` Gao Xiang
2021-03-22 12:43           ` Brian Foster
2021-03-22 12:50             ` Gao Xiang
2021-03-22 16:42               ` Darrick J. Wong
2021-03-23  1:15                 ` Gao Xiang
2021-03-05  2:57 ` [PATCH v8 5/5] xfs: add error injection for per-AG resv failure Gao Xiang
2021-03-09 18:05   ` Darrick J. Wong
2021-03-09 18:44     ` Gao Xiang

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=20210322123328.GA2007006@xiangao.remote.csb \
    --to=hsiangkao@redhat.com \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --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