From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH 04/10 v5] ext4: track all extent status in extent status tree
Date: Fri, 15 Feb 2013 14:45:11 +0800 [thread overview]
Message-ID: <20130215064511.GB26945@gmail.com> (raw)
In-Reply-To: <20130211122127.GB5318@quack.suse.cz>
On Mon, Feb 11, 2013 at 01:21:27PM +0100, Jan Kara wrote:
> On Fri 08-02-13 16:44:00, Zheng Liu wrote:
> > From: Zheng Liu <wenqing.lz@taobao.com>
> >
> > By recording the phycisal block and status, extent status tree is able
> > to track the status of every extents. When we call _map_blocks
> > functions to lookup an extent or create a new written/unwritten/delayed
> > extent, this extent will be inserted into extent status tree. The hole
> > extent is inserted in ext4_ext_put_gap_in_cache(). If there is no any
> > extent, we will not insert a hole extent [0, ~0] into the extent status
> > tree in order to reduce the complextiy of code.
> >
> > We don't load all extents from disk in alloc_inode() because it costs
> > too much memory, and if a file is opened and closed frequently it will
> > takes too much time to load all extent information. So currently when
> > we create/lookup an extent, this extent will be inserted into extent
> > status tree. Hence, the extent status tree may not comprehensively
> > contain all of the extents found in the file.
> >
> > Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
> > Cc: "Theodore Ts'o" <tytso@mit.edu>
> > Cc: Jan kara <jack@suse.cz>
> > ---
> > fs/ext4/extents.c | 4 +--
> > fs/ext4/extents_status.c | 27 ++++++++++++------
> > fs/ext4/extents_status.h | 4 +--
> > fs/ext4/file.c | 4 +--
> > fs/ext4/inode.c | 68 ++++++++++++++++++++++++++++-----------------
> > include/trace/events/ext4.h | 4 +--
> > 6 files changed, 70 insertions(+), 41 deletions(-)
> >
> ...
> > diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
> > index 5093cee..71cb75a 100644
> > --- a/fs/ext4/extents_status.c
> > +++ b/fs/ext4/extents_status.c
> > @@ -239,14 +239,15 @@ static struct extent_status *__es_tree_search(struct rb_root *root,
> > * EXT_MAX_BLOCKS if no extent is found.
> > * Delayed extent is returned via @es.
> > */
> > -ext4_lblk_t ext4_es_find_extent(struct inode *inode, struct extent_status *es)
> > +ext4_lblk_t ext4_es_find_delayed_extent(struct inode *inode,
> > + struct extent_status *es)
> > {
> I have to say I'm still not very happy about this function (but it's much
> better than it used to be so thanks for that!). I have two suggestions for
> improvement:
> 1) 'es' is both input and output argument where for input only es_lblk is
> used. That's a bit confusing so how about making the function like:
>
> ext4_es_find_delayed_extent(struct inode *inode, ext4_lblk_t offset,
> struct extent_status *out);
>
> to separate input and output? Also you can comment that we use the 'out'
> parameter instead of returning the extent_status from the tree because that
> can be freed once we drop the spinlock protecting status tree.
>
> 2) The returned value is somewhat surprisingly the logical offset of the
> *next* delalloc extent. It's used only in ext4_fill_fiemap_extents()
> AFAICS. It would be easier to understand if the function didn't return
> anything. ext4_fill_fiemap_extents() would use
> ext4_es_find_delayed_extent() to find both current and next delalloc extent
> (which would become the 'current' one in the next iteration). As a bonus
> you would also save some iteration of the extent status tree...
I have seen that Ted has sent out two patches that split this patch. I
will pick them up and polish them according to your comments. But
before this, I need to fix the problem that triggers a failure of
xfstests #13 with bigalloc.
Thanks,
- Zheng
next prev parent reply other threads:[~2013-02-15 6:30 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-08 8:43 [PATCH 00/10 v5] ext4: extent status tree (step2) Zheng Liu
2013-02-08 8:43 ` [PATCH 01/10 v5] ext4: refine extent status tree Zheng Liu
2013-02-08 15:35 ` Jan Kara
2013-02-15 6:38 ` Zheng Liu
2013-02-08 8:43 ` [PATCH 02/10 v5] ext4: add physical block and status member into " Zheng Liu
2013-02-08 15:39 ` Jan Kara
2013-02-08 8:43 ` [PATCH 03/10 v5] ext4: let ext4_ext_map_blocks return EXT4_MAP_UNWRITTEN flag Zheng Liu
2013-02-08 15:41 ` Jan Kara
2013-02-08 8:44 ` [PATCH 04/10 v5] ext4: track all extent status in extent status tree Zheng Liu
2013-02-11 12:21 ` Jan Kara
2013-02-15 6:45 ` Zheng Liu [this message]
2013-02-13 3:28 ` Theodore Ts'o
2013-02-13 3:46 ` [PATCH 1/2] ext4: rename ext4_es_find_extent() to ext4_es_find_delayed_extent() Theodore Ts'o
2013-02-13 3:46 ` [PATCH 2/2] ext4: track all extent status in extent status tree Theodore Ts'o
2013-02-15 6:53 ` [PATCH 04/10 v5] " Zheng Liu
2013-02-17 16:26 ` Zheng Liu
2013-02-08 8:44 ` [PATCH 05/10 v5] ext4: lookup block mapping " Zheng Liu
2013-02-12 12:31 ` Jan Kara
2013-02-15 7:06 ` Zheng Liu
2013-02-15 16:47 ` Jan Kara
2013-02-15 17:25 ` Theodore Ts'o
2013-02-16 2:32 ` Zheng Liu
2013-02-16 16:18 ` Possible TODO projects for the map_blocks() code path (was: Re: [PATCH 05/10 v5] ext4: lookup block mapping in extent status tree) Theodore Ts'o
2013-02-17 3:15 ` Zheng Liu
2013-02-08 8:44 ` [PATCH 06/10 v5] ext4: remove single extent cache Zheng Liu
2013-02-08 8:44 ` [PATCH 07/10 v5] ext4: adjust some functions for reclaiming extents from extent status tree Zheng Liu
2013-02-08 8:44 ` [PATCH 08/10 v5] ext4: reclaim " Zheng Liu
2013-02-08 8:44 ` [PATCH 09/10 v5] ext4: convert unwritten extents from extent status tree in end_io Zheng Liu
2013-02-10 8:45 ` Zheng Liu
2013-02-11 1:52 ` Theodore Ts'o
2013-02-12 12:51 ` Jan Kara
2013-02-15 7:12 ` Zheng Liu
2013-02-08 8:44 ` [PATCH 10/10 v5] ext4: remove bogus wait for unwritten extents in ext4_ind_direct_IO Zheng Liu
2013-02-12 12:58 ` Jan Kara
2013-02-15 7:14 ` Zheng Liu
2013-02-10 1:38 ` [PATCH 00/10 v5] ext4: extent status tree (step2) Theodore Ts'o
2013-02-10 8:40 ` Zheng Liu
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=20130215064511.GB26945@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wenqing.lz@taobao.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.