On Fri 15-02-13 15:06:26, Zheng Liu wrote: > 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@xxxxxxxxxx> > > > > > > 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. Ah right, thanks for explanation. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
