All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/8] xfs: plumb in needed functions for range querying of the freespace btrees
Date: Tue, 21 Feb 2017 09:22:44 -0800	[thread overview]
Message-ID: <20170221172244.GE5846@birch.djwong.org> (raw)
In-Reply-To: <20170221143504.GB3207@bfoster.bfoster>

On Tue, Feb 21, 2017 at 09:35:04AM -0500, Brian Foster wrote:
> On Fri, Feb 17, 2017 at 05:17:30PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > Plumb in the pieces (init_high_key, diff_two_keys) necessary to call
> > query_range on the free space btrees.  Remove the debugging asserts
> > so that we can make queries starting from block 0.
> > 
> > While we're at it, merge the redundant "if (btnum ==" hunks.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  fs/xfs/libxfs/xfs_alloc_btree.c |  162 +++++++++++++++++++++++++++++----------
> >  1 file changed, 119 insertions(+), 43 deletions(-)
> > 
> > 
> > diff --git a/fs/xfs/libxfs/xfs_alloc_btree.c b/fs/xfs/libxfs/xfs_alloc_btree.c
> > index efb467b..ba3ec9c 100644
> > --- a/fs/xfs/libxfs/xfs_alloc_btree.c
> > +++ b/fs/xfs/libxfs/xfs_alloc_btree.c
> ...
> > @@ -346,44 +388,78 @@ const struct xfs_buf_ops xfs_allocbt_buf_ops = {
> ...
> > -static const struct xfs_btree_ops xfs_allocbt_ops = {
> > +static const struct xfs_btree_ops xfs_cntbt_ops = {
> >  	.rec_len		= sizeof(xfs_alloc_rec_t),
> >  	.key_len		= sizeof(xfs_alloc_key_t),
> >  
> > @@ -397,11 +473,12 @@ static const struct xfs_btree_ops xfs_allocbt_ops = {
> >  	.init_key_from_rec	= xfs_allocbt_init_key_from_rec,
> >  	.init_rec_from_cur	= xfs_allocbt_init_rec_from_cur,
> >  	.init_ptr_from_cur	= xfs_allocbt_init_ptr_from_cur,
> > -	.key_diff		= xfs_allocbt_key_diff,
> > +	.key_diff		= xfs_cntbt_key_diff,
> >  	.buf_ops		= &xfs_allocbt_buf_ops,
> > +	.diff_two_keys		= xfs_cntbt_diff_two_keys,
> 
> Any reason we add diff_two_keys() but not init_high_key_from_rec() for
> the cntbt? If so.. could you note the different requirements in the
> commit log?

Come to think of it, the cntbt isn't overlapped and nothing ever calls
query_range on it, so we don't need xfs_cntbt_diff_two_keys at all.

That said, between getfsmap and the scrub patches we eventually make all
the other btree types query_range-able, so there's no reason to leave
this subtle logic bomb in libxfs for someone else to trip over later.

Thanks for the review!

--D

> 
> Brian
> 
> >  #if defined(DEBUG) || defined(XFS_WARN)
> > -	.keys_inorder		= xfs_allocbt_keys_inorder,
> > -	.recs_inorder		= xfs_allocbt_recs_inorder,
> > +	.keys_inorder		= xfs_cntbt_keys_inorder,
> > +	.recs_inorder		= xfs_cntbt_recs_inorder,
> >  #endif
> >  };
> >  
> > @@ -427,16 +504,15 @@ xfs_allocbt_init_cursor(
> >  	cur->bc_mp = mp;
> >  	cur->bc_btnum = btnum;
> >  	cur->bc_blocklog = mp->m_sb.sb_blocklog;
> > -	cur->bc_ops = &xfs_allocbt_ops;
> > -	if (btnum == XFS_BTNUM_BNO)
> > -		cur->bc_statoff = XFS_STATS_CALC_INDEX(xs_abtb_2);
> > -	else
> > -		cur->bc_statoff = XFS_STATS_CALC_INDEX(xs_abtc_2);
> >  
> >  	if (btnum == XFS_BTNUM_CNT) {
> > +		cur->bc_statoff = XFS_STATS_CALC_INDEX(xs_abtc_2);
> > +		cur->bc_ops = &xfs_cntbt_ops;
> >  		cur->bc_nlevels = be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNT]);
> >  		cur->bc_flags = XFS_BTREE_LASTREC_UPDATE;
> >  	} else {
> > +		cur->bc_statoff = XFS_STATS_CALC_INDEX(xs_abtb_2);
> > +		cur->bc_ops = &xfs_bnobt_ops;
> >  		cur->bc_nlevels = be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNO]);
> >  	}
> >  
> > 
> > --
> > 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
> --
> 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-02-21 17:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-18  1:17 [RFC PATCH v6 0/8] vfs/xfs/ext4: GETFSMAP support Darrick J. Wong
2017-02-18  1:17 ` [PATCH 1/8] vfs: add common GETFSMAP ioctl definitions Darrick J. Wong
2017-02-18  1:17 ` [PATCH 2/8] xfs: plumb in needed functions for range querying of the freespace btrees Darrick J. Wong
2017-02-21 14:35   ` Brian Foster
2017-02-21 17:22     ` Darrick J. Wong [this message]
2017-02-21 17:34   ` [PATCH v2 " Darrick J. Wong
2017-02-22 15:02     ` Brian Foster
2017-02-18  1:17 ` [PATCH 3/8] xfs: provide a query_range function for " Darrick J. Wong
2017-02-21 14:35   ` Brian Foster
2017-02-18  1:17 ` [PATCH 4/8] xfs: create a function to query all records in a btree Darrick J. Wong
2017-02-21 14:35   ` Brian Foster
2017-02-18  1:17 ` [PATCH 5/8] xfs: introduce the XFS_IOC_GETFSMAP ioctl Darrick J. Wong
2017-02-22 15:02   ` Brian Foster
2017-02-22 21:17     ` Darrick J. Wong
2017-02-23 14:45       ` Brian Foster
2017-02-23 20:44         ` Darrick J. Wong
2017-02-23 23:43           ` Brian Foster
2017-02-24  0:54             ` Darrick J. Wong
2017-02-18  1:17 ` [PATCH 6/8] xfs: have getfsmap fall back to the freesp btrees when rmap is not present Darrick J. Wong
2017-02-24 13:04   ` Brian Foster
2017-02-24 17:48     ` Darrick J. Wong
2017-02-24 22:33       ` Darrick J. Wong
2017-02-18  1:18 ` [PATCH 7/8] xfs: getfsmap should fall back to rtbitmap when rtrmapbt " Darrick J. Wong
2017-02-18  1:18 ` [PATCH 8/8] ext4: support GETFSMAP ioctls Darrick J. Wong
2017-02-21 22:14 ` [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl 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=20170221172244.GE5846@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=bfoster@redhat.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.