All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Gao Xiang <hsiangkao@redhat.com>
Cc: Brian Foster <bfoster@redhat.com>,
	linux-xfs@vger.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 09:38:10 -0700	[thread overview]
Message-ID: <20210322163810.GD22100@magnolia> (raw)
In-Reply-To: <20210322123328.GA2007006@xiangao.remote.csb>

On Mon, Mar 22, 2021 at 08:33:28PM +0800, Gao Xiang wrote:
> 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 */

Yes, all this is born out of paranoia checks on my part because I feel
that shrink is likely to have Real Bad Dataloss Consequences(tm) if we
don't check everything a second time before proceeding.

--D

> > 	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 16:39 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
2021-03-22 16:38           ` Darrick J. Wong [this message]
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=20210322163810.GD22100@magnolia \
    --to=djwong@kernel.org \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=hsiangkao@redhat.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.