All of lore.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 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.