public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <aelder@sgi.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/9] xfs: remove if_lastex
Date: Fri, 20 May 2011 15:17:47 -0500	[thread overview]
Message-ID: <1305922667.1964.58.camel@doink> (raw)
In-Reply-To: <20110511150711.549194744@bombadil.infradead.org>

On Wed, 2011-05-11 at 11:04 -0400, Christoph Hellwig wrote:
> plain text document attachment (xfs-kill-if_lastex)
> The if_lastex field in struct xfs_ifork is only used as a temporary index
> during xfs_bmapi and xfs_bmapi.  Instead of using the inode fork to store

                      xfs_bunmapi

(I'll fix this for you when I commit the change.)

> it keep it local in the callchain.  Fortunately this is very easy as
> we already pass a stack copy of it down the whole chain which can simplify
> be changed to be passed by reference.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

This looks good to me.  I have a few comments below but
nothing looks incorrect.

Reviewed-by: Alex Elder <aelder@sgi.com>

I will continue with patches 3-9 a little later on.

> Index: xfs/fs/xfs/xfs_bmap.c
> ===================================================================
> --- xfs.orig/fs/xfs/xfs_bmap.c	2011-05-10 13:20:21.182349200 +0200
> +++ xfs/fs/xfs/xfs_bmap.c	2011-05-10 13:29:40.618349159 +0200

. . .

> @@ -725,14 +709,13 @@ xfs_bmap_add_extent_delay_real(
>  		 * Filling in all of a previously delayed allocation extent.
>  		 * The left and right neighbors are both contiguous with new.
>  		 */

Couldn't you decrement *idx here, and use its value
(without subtracting 1) in almost all spots below...

> -		trace_xfs_bmap_pre_update(ip, idx - 1, state, _THIS_IP_);
> -		xfs_bmbt_set_blockcount(xfs_iext_get_ext(ifp, idx - 1),
> +		trace_xfs_bmap_pre_update(ip, *idx - 1, state, _THIS_IP_);
> +		xfs_bmbt_set_blockcount(xfs_iext_get_ext(ifp, *idx - 1),
>  			LEFT.br_blockcount + PREV.br_blockcount +
>  			RIGHT.br_blockcount);
> -		trace_xfs_bmap_post_update(ip, idx - 1, state, _THIS_IP_);
> +		trace_xfs_bmap_post_update(ip, *idx - 1, state, _THIS_IP_);
>  
> -		xfs_iext_remove(ip, idx, 2, state);
> -		ip->i_df.if_lastex = idx - 1;
> +		xfs_iext_remove(ip, *idx, 2, state);
...(but pass *idx + 1 here)...
>  		ip->i_d.di_nextents--;
>  		if (cur == NULL)
>  			rval = XFS_ILOG_CORE | XFS_ILOG_DEXT;
> @@ -756,6 +739,8 @@ xfs_bmap_add_extent_delay_real(
>  					RIGHT.br_blockcount, LEFT.br_state)))
>  				goto done;
>  		}
> +
> +		--*idx;

...rather than waiting until here to do the decrement?

>  		*dnew = 0;
>  		break;
>  
> @@ -764,13 +749,12 @@ xfs_bmap_add_extent_delay_real(
>  		 * Filling in all of a previously delayed allocation extent.
>  		 * The left neighbor is contiguous, the right is not.
>  		 */

Same general comment in this section (and in some others
that follow).

This is not a big deal at all, but I did notice that you
did the decrement (or increment) earlier in some spots
below, but not in these.  I see nothing incorrect,
just saw what seemed like inconsistency and wondered
if there was a reasaon.

> -		trace_xfs_bmap_pre_update(ip, idx - 1, state, _THIS_IP_);
> -		xfs_bmbt_set_blockcount(xfs_iext_get_ext(ifp, idx - 1),
> +		trace_xfs_bmap_pre_update(ip, *idx - 1, state, _THIS_IP_);
> +		xfs_bmbt_set_blockcount(xfs_iext_get_ext(ifp, *idx - 1),
>  			LEFT.br_blockcount + PREV.br_blockcount);
> -		trace_xfs_bmap_post_update(ip, idx - 1, state, _THIS_IP_);
> +		trace_xfs_bmap_post_update(ip, *idx - 1, state, _THIS_IP_);
>  
> -		ip->i_df.if_lastex = idx - 1;
> -		xfs_iext_remove(ip, idx, 1, state);
> +		xfs_iext_remove(ip, *idx, 1, state);
>  		if (cur == NULL)
>  			rval = XFS_ILOG_DEXT;
>  		else {
. . .

> @@ -1468,17 +1458,19 @@ xfs_bmap_add_extent_unwritten_real(
>  		 * Setting the last part of a previous oldext extent to newext.
>  		 * The right neighbor is contiguous with the new allocation.
>  		 */
> -		trace_xfs_bmap_pre_update(ip, idx, state, _THIS_IP_);
> -		trace_xfs_bmap_pre_update(ip, idx + 1, state, _THIS_IP_);

This one was a bit weird (second trace call being out of place).

> +		trace_xfs_bmap_pre_update(ip, *idx, state, _THIS_IP_);
>  		xfs_bmbt_set_blockcount(ep,
>  			PREV.br_blockcount - new->br_blockcount);
> -		trace_xfs_bmap_post_update(ip, idx, state, _THIS_IP_);
> -		xfs_bmbt_set_allf(xfs_iext_get_ext(ifp, idx + 1),
> +		trace_xfs_bmap_post_update(ip, *idx, state, _THIS_IP_);
> +
> +		++*idx;
> +
> +		trace_xfs_bmap_pre_update(ip, *idx, state, _THIS_IP_);
> +		xfs_bmbt_set_allf(xfs_iext_get_ext(ifp, *idx),
>  			new->br_startoff, new->br_startblock,
>  			new->br_blockcount + RIGHT.br_blockcount, newext);
> -		trace_xfs_bmap_post_update(ip, idx + 1, state, _THIS_IP_);
> +		trace_xfs_bmap_post_update(ip, *idx, state, _THIS_IP_);
>  
> -		ip->i_df.if_lastex = idx + 1;
>  		if (cur == NULL)
>  			rval = XFS_ILOG_DEXT;
>  		else {

. . .



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-05-20 21:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 15:04 [PATCH 0/9] extent buffer indexing fixes Christoph Hellwig
2011-05-11 15:04 ` [PATCH 1/9] xfs: remove the unused XFS_BMAPI_RSVBLOCKS flag Christoph Hellwig
2011-05-20 20:17   ` Alex Elder
2011-05-11 15:04 ` [PATCH 2/9] xfs: remove if_lastex Christoph Hellwig
2011-05-20 20:17   ` Alex Elder [this message]
2011-05-23  8:52   ` [PATCH 2/9 v2] " Christoph Hellwig
2011-05-25  1:14     ` Alex Elder
2011-05-11 15:04 ` [PATCH 3/9] xfs: correctly decrement the extent buffer index in xfs_bmap_del_extent Christoph Hellwig
2011-05-12  6:50   ` Lachlan McIlroy
2011-05-12  6:54     ` Lachlan McIlroy
2011-05-12  7:17   ` Lachlan McIlroy
2011-05-25  0:27   ` Alex Elder
2011-05-11 15:04 ` [PATCH 4/9] xfs: do not use unchecked extent indices in xfs_bmap_add_extent_* Christoph Hellwig
2011-05-12  7:31   ` Lachlan McIlroy
2011-05-25  0:30   ` Alex Elder
2011-05-11 15:04 ` [PATCH 5/9] xfs: do not use unchecked extent indices in xfs_bmapi Christoph Hellwig
2011-05-12  7:20   ` Lachlan McIlroy
2011-05-25  0:31   ` Alex Elder
2011-05-11 15:04 ` [PATCH 6/9] xfs: do not use unchecked extent indices in xfs_bunmapi Christoph Hellwig
2011-05-12  7:22   ` Lachlan McIlroy
2011-05-25  0:31   ` Alex Elder
2011-05-11 15:04 ` [PATCH 7/9] xfs: do not do pointer arithmetics on extent records Christoph Hellwig
2011-05-12  7:23   ` Lachlan McIlroy
2011-05-25  0:31   ` Alex Elder
2011-05-11 15:04 ` [PATCH 8/9] xfs: fix up asserts in xfs_iflush_fork Christoph Hellwig
2011-05-12  7:24   ` Lachlan McIlroy
2011-05-25  0:32   ` Alex Elder
2011-05-11 15:04 ` [PATCH 9/9] xfs: check for valid indices in xfs_iext_get_ext and xfs_iext_idx_to_irec Christoph Hellwig
2011-05-12  7:26   ` Lachlan McIlroy
2011-05-25  0:32   ` Alex Elder

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=1305922667.1964.58.camel@doink \
    --to=aelder@sgi.com \
    --cc=hch@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox