From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 21/26] implement generic xfs_btree_inѕert/insrec
Date: Tue, 5 Aug 2008 11:05:57 +1000 [thread overview]
Message-ID: <20080805010557.GL6119@disturbed> (raw)
In-Reply-To: <20080804013535.GV8819@lst.de>
On Mon, Aug 04, 2008 at 03:35:35AM +0200, Christoph Hellwig wrote:
> Make the btree insert code generic. Based on a patch from David Chinner
> with lots of changes to follow the original btree implementations more
> closely. While this loses some of the generic helper routines for
> inserting/moving/removing records it also solves some of the one off
> bugs in the original code and makes it easier to verify.
....
> + if (cur->bc_flags & XFS_BTREE_ROOT_IN_INODE) {
> + if (numrecs < cur->bc_ops->get_dmaxrecs(cur, level)) {
> + /* A resizeable root block that can be made bigger. */
> + cur->bc_ops->realloc_root(cur, 1);
> + return 0;
> + }
I think that ->get_dmaxrecs is probably badly named. I called it
that originally because it matched the macro name it was wrapping.
Realisitically it should be ->get_root_maxrecs....
> + /* Make a key out of the record data to be inserted, and save it. */
> + cur->bc_ops->init_key_from_rec(cur, &key, recp);
> +
> + /* If we're off the left edge, return failure. */
> + ptr = cur->bc_ptrs[level];
> + if (ptr == 0) {
> + XFS_BTREE_TRACE_CURSOR(cur, XBT_EXIT);
> + *stat = 0;
> + return 0;
> + }
You can probably move the key initialisation till after then initial
'in this block' checks.
> + /*
> + * If the block is full, we can't insert the new entry until we
> + * make the block un-full.
> + */
> + xfs_btree_set_ptr_null(cur, &nptr);
> + if (numrecs == cur->bc_ops->get_maxrecs(cur, level)) {
> + error = xfs_btree_make_block_unfull(cur, level, numrecs,
> + &optr, &ptr, &nptr, &ncur, &nrec, stat);
> + if (error || *stat == 0)
> + goto error0;
> + }
> +
> + /* The current block may have changed during the split. */
> + block = xfs_btree_get_block(cur, level, &bp);
> + numrecs = xfs_btree_get_numrecs(block);
The comment here should probably refer to the unfull call, not a
'split'. i.e.:
/*
* the current block may have changed if the block was
* previously full and we have just made space in it.
*/
Otherwise looks good.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2008-08-05 1:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-04 1:35 [PATCH 21/26] implement =?unknown-8bit?Q?generic_xfs=5Fbtree=5Fin=D1=95ert=2Finsrec?= Christoph Hellwig
2008-08-05 1:05 ` Dave Chinner [this message]
2008-08-05 1:29 ` [PATCH 21/26] implement generic xfs_btree_in??ert/insrec 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=20080805010557.GL6119@disturbed \
--to=david@fromorbit.com \
--cc=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.