linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs_db: calculate iext tree geometry in btheight command
Date: Thu, 26 Sep 2019 19:58:57 -0700	[thread overview]
Message-ID: <20190927025857.GK9916@magnolia> (raw)
In-Reply-To: <20190926214102.GK16973@dread.disaster.area>

On Fri, Sep 27, 2019 at 07:41:02AM +1000, Dave Chinner wrote:
> On Wed, Sep 25, 2019 at 02:40:59PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > (Ab)use the btheight command to calculate the geometry of the incore
> > extent tree.
> > 
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> >  db/btheight.c |   87 +++++++++++++++++++++++++++++++++++++++------------------
> >  1 file changed, 60 insertions(+), 27 deletions(-)
> > 
> > 
> > diff --git a/db/btheight.c b/db/btheight.c
> > index e2c9759f..be604ebc 100644
> > --- a/db/btheight.c
> > +++ b/db/btheight.c
> > @@ -22,18 +22,37 @@ static int rmap_maxrecs(struct xfs_mount *mp, int blocklen, int leaf)
> >  	return libxfs_rmapbt_maxrecs(blocklen, leaf);
> >  }
> >  
> > +static int iext_maxrecs(struct xfs_mount *mp, int blocklen, int leaf)
> > +{
> > +	blocklen -= 2 * sizeof(void *);
> > +
> > +	return blocklen / sizeof(struct xfs_bmbt_rec);
> > +}
> 
> This isn't correct for the iext nodes. They hold 16 key/ptr pairs,
> not 15.
> 
> I suspect you should be lifting the iext btree format definitions
> like this one:
> 
> enum {                                                                           
>         NODE_SIZE       = 256,                                                   
>         KEYS_PER_NODE   = NODE_SIZE / (sizeof(uint64_t) + sizeof(void *)),       
>         RECS_PER_LEAF   = (NODE_SIZE - (2 * sizeof(struct xfs_iext_leaf *))) /   
>                                 sizeof(struct xfs_iext_rec),                     
> };                                                                               
> 
> from libxfs/xfs_iext_tree.c to a libxfs header file and then using
> KEYS_PER_NODE and RECS_PER_LEAF here. See the patch below, lifted
> from a varaint of my range locking prototypes...
> 
> However, these are not on-disk values and so are subject to change,
> hence it may be that a warning might be needed when xfs_db is used
> to calculate the height of this tree.

Er... I don't mind lifting the iext values, but I don't see a patch?

--D

> > +static int disk_blocksize(struct xfs_mount *mp)
> > +{
> > +	return mp->m_sb.sb_blocksize;
> > +}
> > +
> > +static int iext_blocksize(struct xfs_mount *mp)
> > +{
> > +	return 256;
> > +}
> 
> NODE_SIZE....
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

  reply	other threads:[~2019-09-27  2:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 21:40 [PATCH 0/2] xfs_db: fixes to the btheight command Darrick J. Wong
2019-09-25 21:40 ` [PATCH 1/2] xfs_db: btheight should check geometry more carefully Darrick J. Wong
2019-09-26  9:11   ` Carlos Maiolino
2019-09-26 17:38     ` Darrick J. Wong
2019-09-27 12:30       ` Carlos Maiolino
2019-09-26 19:09   ` [PATCH v2 " Darrick J. Wong
2019-10-01  6:40     ` Carlos Maiolino
2019-09-30  7:55   ` [PATCH " Christoph Hellwig
2019-09-25 21:40 ` [PATCH 2/2] xfs_db: calculate iext tree geometry in btheight command Darrick J. Wong
2019-09-26  9:20   ` Carlos Maiolino
2019-09-26 17:40     ` Darrick J. Wong
2019-09-26 19:09   ` [PATCH v2 " Darrick J. Wong
2019-09-26 21:41   ` [PATCH " Dave Chinner
2019-09-27  2:58     ` Darrick J. Wong [this message]
2019-09-27 22:08       ` Dave Chinner
2019-09-30  7:58     ` Christoph Hellwig
2019-09-30 16:11       ` Darrick J. Wong
2019-10-01  6:24         ` Christoph Hellwig

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=20190927025857.GK9916@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=david@fromorbit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).