All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: [EXT4 set 9][PATCH 5/5]Extent micro cleanups
Date: Wed, 11 Jul 2007 17:29:35 -0400	[thread overview]
Message-ID: <1184189375.3886.31.camel@localhost.localdomain> (raw)
In-Reply-To: <20070710232008.599b25aa.akpm@linux-foundation.org>

On Tue, 2007-07-10 at 23:20 -0700, Andrew Morton wrote:
> On Sun, 01 Jul 2007 03:38:59 -0400 Mingming Cao <cmm@us.ibm.com> wrote:
> 
> > From: Dmitry Monakhov <dmonakhov@sw.ru>
> > Subject: ext4: extent macros cleanup
> > 
> > - Replace math equation to it's macro equivalent
> 
> s/it's/its/;)
Okay.

> 
> > - make ext4_ext_grow_indepth() indexes/leaf correct
> 
> hm, what was wrong with it?
> 
Looking at the code, ext4_ext_ext_grow_indepth() implements tree growing
procedure. It allocates a new index block, moves the top-level data of
the tree(root or leaf blocks in i_data) into the new block, initializes
the new root, creating index that points to the just created index block

The original top-level data (in i_data) could be extent tree root (index
block) or extents (leaf block). The current code (without the patch)
treats the top-level data always be the leaf block, which is incorrect.


assumes when the tree is growing the extent structure pass in is always
> > @@ -922,8 +922,11 @@ static int ext4_ext_grow_indepth(handle_t *handle, struct inode *inode,
> >  	curp->p_hdr->eh_max = cpu_to_le16(ext4_ext_space_root_idx(inode));
> >  	curp->p_hdr->eh_entries = cpu_to_le16(1);
> >  	curp->p_idx = EXT_FIRST_INDEX(curp->p_hdr);
> > -	/* FIXME: it works, but actually path[0] can be index */
> > -	curp->p_idx->ei_block = EXT_FIRST_EXTENT(path[0].p_hdr)->ee_block;
> > +	
> > +	if (path[0].p_hdr->eh_depth)
> > +	  curp->p_idx->ei_block = EXT_FIRST_INDEX(path[0].p_hdr)->ei_block;
> > +	else
> > +	  curp->p_idx->ei_block = EXT_FIRST_EXTENT(path[0].p_hdr)->ee_block;
> 
> whitespace bustage there.
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2007-07-12  0:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01  7:38 [EXT4 set 9][PATCH 5/5]Extent micro cleanups Mingming Cao
2007-07-11  6:20 ` Andrew Morton
2007-07-11 21:29   ` Mingming Cao [this message]

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=1184189375.3886.31.camel@localhost.localdomain \
    --to=cmm@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.