Re: [PATCH 05/10 v5] ext4: lookup block mapping in extent status tree

[Zheng Liu <gnehzuil.liu@gmail.com>]

On Tue, Feb 12, 2013 at 01:31:42PM +0100, Jan Kara wrote:
> On Fri 08-02-13 16:44:01, Zheng Liu wrote:
> > From: Zheng Liu <wenqing.lz@taobao.com>
> > 
> > After tracking all extent status, we already have a extent cache in
> > memory.  Every time we want to lookup a block mapping, we can first
> > try to lookup it in extent status tree to avoid a potential disk I/O.
> > 
> > A new function called ext4_es_lookup_extent is defined to finish this
> > work.  When we try to lookup a block mapping, we always call
> > ext4_map_blocks and/or ext4_da_map_blocks.  So in these functions we
> > first try to lookup a block mapping in extent status tree.
> > 
> > A new flag EXT4_GET_BLOCKS_NO_PUT_HOLE is used in ext4_da_map_blocks
> > in order not to put a hole into extent status tree because this hole
> > will be converted to delayed extent in the tree immediately.
>   It looks somewhat inconsistent that you put hole into the extent tree in
> ext4_ext_map_blocks() but all other extent types are handled in
> ext4_map_blocks() or ext4_da_map_blocks(). Can we put the handling in one
> place?

It seems that putting all handlings in one place is too complex because
ext4_da_map_blocks() calls ext4_ext_map_blocks() and ext4_ind_map_blocks()
directly.  So now we put all extent except hole in ext4_map_blocks() and
ext4_da_map_blocks().  For the hole, it will be inserted into the status
tree in ext4_ext_put_gap_in_cache().  In this function we can get the
the length of the hole.  If we handle it in ext4_da_map_blocks() or
ext4_map_blocks(), we only can insert a hole which the length of this
hole is 1 because in these functions we couldn't know the length of the
hole.

I am planning to refine the get_block_t and *map_blocks functions.  At
that time I will try to fix this problem.

Thanks,
                                                - Zheng