在塊分配機制中，涉及到幾個主要的數(shù)據(jù)結構。

　　通過ext4_allocation_request描述塊請求，然后基于塊查找結果即上層需求來決定是否執(zhí)行塊分配操作。

　　在分配過程中，為了更好執(zhí)行分配，記錄一些信息，需要對分配行為進行描述，就有結構體ext4_allocation_contex。

　　在搜尋可用空間過程中，是有可能使用預分配空間的，因此還需要有能夠描述預分配空間大小等屬性的描述符ext4_prealloc_space。

　　下面，對各個關鍵結構體進行詳細的分析。

　　1. 塊請求描述符ext4_allocation_request

　　塊分配請求屬性，有請求描述符ext4_allocation_request來描述：

　　structext4_allocation_request {

　　/* target inode for block wereallocating */

　　struct inode *inode;

　　/* how many blocks we want to allocate*/

　　unsigned int len;

　　/* logical block in target inode */

　　ext4_lblk_t logical;

　　/* the closest logical allocated blockto the left */

　　ext4_lblk_t lleft;

　　/* the closest logical allocated blockto the right */

　　ext4_lblk_t lright;

　　/* phys. target (a hint) */

　　ext4_fsblk_t goal;

　　/* phys. block for the closest logicalallocated block to the left */

　　ext4_fsblk_t pleft;

　　/* phys. block for the closest logicalallocated block to the right */

　　ext4_fsblk_t pright;

　　/* flags. see above EXT4_MB_HINT_* */

　　unsigned int flags;

　　};

　　這個請求描述符結構體在ext4_ext_map_blocks()中初始化(注：ext4_ext_map_blocks()的作用是查找或分配指定的block塊，并完成與緩存空間的映射)。

　　具體上述信息也就一個成員變量goal值的我們分析一下，goal記錄是物理塊號，其隱含含義比較重要：goal雖然只是記錄物理塊號，但是這個物理塊號的選擇可以很大程度的是文件保證locality特性及其物理地址連續(xù)性。

　　goal是由函數(shù)ext4_ext_find_goal()來定義：

　　static ext4_fsblk_t ext4_ext_find_goal(struct inode*inode,

　　struct ext4_ext_path *path,

　　ext4_lblk_t block)

　　{

　　if(path) {

　　intdepth = path->p_depth;

　　structext4_extent *ex;

　　/*

　　* Try to predict block placement assuming thatwe are

　　* filling in a file which will eventually be

　　* non-sparse --- i.e., in the case of libbfdwriting

　　* an ELF object sections out-of-order but in away

　　* the eventually results in a contiguousobject or

　　* executable file, or some database extendinga table

　　* space file. However, this is actually somewhat

　　* non-ideal if we are writing a sparse filesuch as

　　* qemu or KVM writing a raw image file that isgoing

　　* to stay fairly sparse, since it will end up

　　* fragmenting the file systems free space. Maybe we

　　* should have some hueristics or some way toallow

　　* userspace to pass a hint to file system,

　　* especially if the latter case turns out tobe

　　* common.

　　*/

　　ex= path[depth].p_ext;

　　if(ex) {

　　ext4_fsblk_text_pblk = ext4_ext_pblock(ex);

　　ext4_lblk_text_block = le32_to_cpu(ex->ee_block);

　　if(block > ext_block)

　　returnext_pblk + (block - ext_block);

　　else

　　returnext_pblk - (ext_block - block);

　　}

　　/*it looks like index is empty;

　　* try to find starting block from index itself*/

　　if(path[depth].p_bh)

　　returnpath[depth].p_bh->b_blocknr;

　　}

　　/*OK. use inodes group */

　　returnext4_inode_to_goal_block(inode);

　　}

　　細細分析這段代碼，如果從根目錄到指定邏輯塊的path存在，那么就需要根據(jù)path來計算目標物理塊的地址。

　　(1) Path的終點若是dataextent，則說明該path是從根到葉子的。當請求block號大于path葉子extent的起始邏輯塊號ext_block (對應物理塊號為pblk)，其邏輯塊的距離為(block-ext_block)，為在最可能上保證對應物理地址的連續(xù)性;只需返回與pblk+(block-ext_block)物理塊號最接近的空閑物理塊即可;而對于請求block號小于extent的起始邏輯塊號ext_block的情況，只需盡最可能以pblk-( ext_block -block)物理塊號為目標尋找與其物理地址最接近的空閑物理塊即可。因此，我們指定goal分別為pblk+(block-ext_block)和pblk-(block-ext_block)。

　　(2) 而如果path存在，卻沒有葉子，那則么辦，很簡單，我們只需要將goal物理塊號指定為最后一個的extent block對應的物理塊號既可。

　　(3) 還有一種情況，沒有給出path。個人認為，這種場景即inode剛create的情況。有專門的ext4_inode_to_goal_block()來實現(xiàn)：

　　ext4_fsblk_t ext4_inode_to_goal_block(struct inode*inode)

　　{

　　structext4_inode_info *ei = EXT4_I(inode);

　　ext4_group_tblock_group;

　　ext4_grpblk_tcolour;

　　intflex_size = ext4_flex_bg_size(EXT4_SB(inode->i_sb));

　　ext4_fsblk_tbg_start;

　　ext4_fsblk_tlast_block;

　　block_group= ei->i_block_group;

　　if(flex_size >= EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME) {

　　/*

　　* If there are at leastEXT4_FLEX_SIZE_DIR_ALLOC_SCHEME

　　* block groups per flexgroup, reserve thefirst block

　　* group for directories and special files. Regular

　　* files will start at the second blockgroup. This

　　* tends to speed up directory access andimproves

　　* fsck times.

　　*/

　　block_group&= ~(flex_size-1);

　　if(S_ISREG(inode->i_mode))

　　block_group++;

　　}

　　bg_start= ext4_group_first_block_no(inode->i_sb, block_group);

　　last_block= ext4_blocks_count(EXT4_SB(inode->i_sb)->s_es) - 1;

　　/*

　　* If we are doing delayed allocation, we dontneed take

　　* colour into account.

　　*/

　　if(test_opt(inode->i_sb, DELALLOC))

　　returnbg_start;

　　if(bg_start + EXT4_BLOCKS_PER_GROUP(inode->i_sb) <= last_block)

　　colour= (current->pid % 16) *

　　(EXT4_BLOCKS_PER_GROUP(inode->i_sb)/ 16);

　　else

　　colour= (current->pid % 16) * ((last_block - bg_start) / 16);

　　returnbg_start + colour;

　　}

　　其思想是：如果flex_size至少有EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME個block groups，則定義inode所在flex_group的第二個block group的首個可用block為起始物理塊號bg_block。

　　當然，如果該flex_group的所有文件都以bg_block為goal的，肯定會產(chǎn)生競爭，所以增加color的作用，目的就是加入一個隨機值，降低可能帶來的競爭。

　　因此,最后這種情況的goal會選擇inode所在flex_group中某個隨機值。

　　【說明：如果flex_size只有不小于EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME，則才有可能將flex_group中第一個group分離出來，用于專門存放directories和一些特殊文件，普通文件從第二個group中分配，該特可以加速directory的訪問及fsync效率?！?/p>

　　2. 分配行為描述符ext4_allocation_contex

　　在分配過程中，為了更好執(zhí)行分配，記錄一些信息，需要對分配行為進行描述，就有結構體ext4_allocation_contex：

　　struct ext4_allocation_context{

　　struct inode *ac_inode;

　　struct super_block *ac_sb;

　　/* original request */

　　struct ext4_free_extent ac_o_ex;

　　/* goal request (normalized ac_o_ex) */

　　struct ext4_free_extent ac_g_ex;

　　/* the best found extent */

　　struct ext4_free_extent ac_b_ex;

　　/* copy of the best found extent takenbefore preallocation efforts */

　　struct ext4_free_extent ac_f_ex;

　　__u16 ac_groups_scanned;

　　__u16 ac_found;

　　__u16 ac_tail;

　　__u16 ac_buddy;

　　__u16 ac_flags; /* allocation hints */

　　__u8 ac_status;

　　__u8 ac_criteria;

　　__u8 ac_2order; /* if request is to allocate 2^N blocks and

　　* N > 0, the field stores N, otherwise 0 */

　　__u8 ac_op; /* operation, for history only */

　　struct page *ac_bitmap_page;

　　struct page *ac_buddy_page;

　　struct ext4_prealloc_space *ac_pa;

　　struct ext4_locality_group *ac_lg;

　　};

　　這個數(shù)據(jù)結構用來描述分配上下文的屬性。基于結構體ext4_allocation_request，由函數(shù)ext4_mb_initialize_context()進行初始化。

　　ext4_mb_initialize_context()主要工作: 利用請求描述符的信息初始化ac->ac_o_ex:申請的邏輯塊號fe_logical、goal所在的group，goal的cluster號(暫時理解為物理塊號);然后將ac_g_ex 賦值為ac_o_ex。

　　ext4_mb_normalize_request()會對ext4_allocation_contex結構體進行normalization：

　　1.計算file的大小size應該是i_size_read(ac->ac_inode)和(offset+請求長度)中的大值，其中offset是有指定block轉化而來。

　　2. 根據(jù)已定的算法估算文件可能的大小;

　　#define NRL_CHECK_SIZE(req, size, max, chunk_size)

　　(req<= (size) || max <= (chunk_size))

　　/*first, try to predict filesize */

　　/*XXX: should this table be tunable? */

　　start_off= 0;

　　if(size <= 16 * 1024) {

　　size= 16 * 1024;

　　}else if (size <= 32 * 1024) {

　　size= 32 * 1024;

　　}else if (size <= 64 * 1024) {

　　size= 64 * 1024;

　　}else if (size <= 128 * 1024) {

　　size= 128 * 1024;

　　}else if (size <= 256 * 1024) {

　　size= 256 * 1024;

　　}else if (size <= 512 * 1024) {

　　size= 512 * 1024;

　　}else if (size <= 1024 * 1024) {

　　size= 1024 * 1024;

　　}else if (NRL_CHECK_SIZE(size, 4 * 1024 * 1024, max, 2 * 1024)) {

　　start_off= ((loff_t)ac->ac_o_ex.fe_logical >>

　　(21- bsbits)) << 21;

　　size= 2 * 1024 * 1024;

　　}else if (NRL_CHECK_SIZE(size, 8 * 1024 * 1024, max, 4 * 1024)) {

　　start_off= ((loff_t)ac->ac_o_ex.fe_logical >>

　　(22- bsbits)) << 22;

　　size= 4 * 1024 * 1024;

　　}else if (NRL_CHECK_SIZE(ac->ac_o_ex.fe_len,

　　(8<<20)>>bsbits,max, 8 * 1024)) {

　　start_off= ((loff_t)ac->ac_o_ex.fe_logical >>

　　(23- bsbits)) << 23;

　　size= 8 * 1024 * 1024;

　　}else {

　　start_off= (loff_t)ac->ac_o_ex.fe_logical << bsbits;

　　size =ac->ac_o_ex.fe_len << bsbits;

　　}

　　size= size >> bsbits;

　　start= start_off >> bsbits;

　　由此可見，預估文件大小之后得到的size和start肯定比原來的要大一些。

　　3. check一下，是否覆蓋了已有的prealloc空間。(如果覆蓋，那就BUG);

　　4. 更新ac_g_ex：根據(jù)(2)中size和start更新ac_g_ex;

　　ac->ac_g_ex.fe_logical= start;

　　ac->ac_g_ex.fe_len= EXT4_NUM_B2C(sbi, size);

　　由上可見，通過ext4_mb_normalize_request()函數(shù)主要更新了ac->ac_g_ex成員。

　　而ac->ac_b_ex是在ext4_mb_regular_allocator()函數(shù)初始化的，其表示可以分配的最佳的extent;隱含意思，就是就按這么分配。

　　而ac-> ac_f_ex是在prealloc空間初始化之前保留ac_b_ex的副本，在ext4_mb_new_inode_pa()或ext4_mb_new_group_pa()中定義。

　　3. 預分配空間描述符ext4_allocation_contex

　　描述預分配空間大小等屬性的描述符ext4_prealloc_space：

　　structext4_prealloc_space {

　　struct list_head pa_inode_list;

　　struct list_head pa_group_list;

　　union {

　　struct list_head pa_tmp_list;

　　struct rcu_head pa_rcu;

　　} u;

　　spinlock_t pa_lock;

　　atomic_t pa_count;

　　unsigned pa_deleted;

　　ext4_fsblk_t pa_pstart; /*phys. block */

　　ext4_lblk_t pa_lstart; /*log. block */

　　ext4_grpblk_t pa_len; /*len of preallocated chunk */

　　ext4_grpblk_t pa_free; /* howmany blocks are free */

　　unsigned short pa_type; /* pa type.inode or group */

　　spinlock_t *pa_obj_lock;

　　struct inode *pa_inode; /*hack, for history only */

　　};

　　其中有四個結構體非常重要：

　　pa_lstart -> prealloc 空間的起始邏輯地址(對文件而言);

　　pa_pstart -> prealloc 空間的起始物理地址;

　　pa_len -> prealloc 空間的長度;

　　pa_free -> prealloc 空間的可用長度;

　　這個結構體是在函數(shù)ext4_mb_new_inode_pa()或ext4_mb_new_group_pa()中初始化。

　　暫時就分析這么幾個結構體吧。

　　作者：Younger Liu，

　　本作品采用知識共享署名-非商業(yè)性使用-相同方式共享 3.0 未本地化版本許可協(xié)議進行許可。