All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: [PATCH 23/26] implement generic xfs_btree_delete/delrec
Date: Tue, 5 Aug 2008 03:45:24 +0200	[thread overview]
Message-ID: <20080805014524.GA6465@lst.de> (raw)
In-Reply-To: <20080805013625.GN6119@disturbed>

On Tue, Aug 05, 2008 at 11:36:25AM +1000, Dave Chinner wrote:
> > +#ifdef DEBUG
> > +	if (cur->bc_btnum == XFS_BTNUM_BNO || cur->bc_btnum == XFS_BTNUM_CNT) {
> > +		struct xfs_buf		*agbp = cur->bc_private.a.agbp;
> > +		struct xfs_agf		*agf = XFS_BUF_TO_AGF(agbp);
> > +
> > +		ASSERT(be32_to_cpu(agf->agf_roots[cur->bc_btnum]) ==
> > +		       XFS_DADDR_TO_AGBNO(cur->bc_mp, XFS_BUF_ADDR(bp)));
> > +	} else if (cur->bc_btnum == XFS_BTNUM_INO) {
> > +		struct xfs_buf		*agbp = cur->bc_private.a.agbp;
> > +		struct xfs_agi		*agi = XFS_BUF_TO_AGI(agbp);
> > +		xfs_fsblock_t		fsbno;
> > +
> > +		fsbno = XFS_AGB_TO_FSB(cur->bc_mp, cur->bc_private.a.agno,
> > +				       be32_to_cpu(agi->agi_root));
> > +
> > +		ASSERT(fsbno == XFS_DADDR_TO_FSB(cur->bc_mp, XFS_BUF_ADDR(bp)));
> > +	}
> > +#endif
> 
> That's kind of messy - can it be pushed out to a separate debug only
> function? Also, why do we check the inobt against a long pointer,
> and the allocbt against a short pointer? both are short pointer
> btrees, so it doesn't really make sense to me to have different
> checks on them...

The old inobt code built a long pointer to pass it to xfs_free_extent,
and this assert validates we get the same block.  The right thing to
do here is to just remove this crap, it was just there to make sure
I didn't add a really bad thinko.

> Otherwise looks pretty good.

Unfortunately it's buggy, though.  The cur->bc_bufs[level] = NULL; vs
xfs_btree_setbuf(cur, level, NULL); does make an enormous difference
for 512byte block size filesystems.  I'll have to find out what's
going on in this area, and to make things worse I remember spotting
a similar different between the ialloc and alloc btrees somewhere
earlier in the series.

  reply	other threads:[~2008-08-05  1:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-04  1:35 [PATCH 23/26] implement generic xfs_btree_delete/delrec Christoph Hellwig
2008-08-05  1:36 ` Dave Chinner
2008-08-05  1:45   ` Christoph Hellwig [this message]
2008-08-05  2:18     ` Dave Chinner

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=20080805014524.GA6465@lst.de \
    --to=hch@lst.de \
    --cc=xfs@oss.sgi.com \
    /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.