On Apr 22, 2008 08:46 -0400, Theodore Ts'o wrote:
> Change the way we allocate bitmaps and inode tables if the FLEX_BG
> feature is used at mke2fs time. It places calculates a new offset for
> bitmaps and inode table base on the number of groups that the user
> wishes to pack together using the new "-G" option. Creating a
> filesystem with 64 block groups in a flex group can be done by:
>
> mke2fs -j -I 256 -O flex_bg -G 32 /dev/sdX
Presumably you mean "-G 64" based on your description of 64 groups/flex_bg?
> @@ -66,6 +137,22 @@ errcode_t ext2fs_allocate_group_table(ext2_filsys fs, dgrp_t group,
> + if (flexbg_size) {
> + dgrp_t gr = ext2fs_group_of_blk(fs, new_blk);
> + fs->group_desc[gr].bg_free_blocks_count--;
> + fs->super->s_free_blocks_count--;
> + fs->group_desc[gr].bg_flags &= ~EXT2_BG_BLOCK_UNINIT;
> + ext2fs_group_desc_csum_set(fs, gr);
> + }
It makes total sense to me that the BG_BLOCK_UNINIT flag would not be set
on a group that does not have the default bitmap layouts, so I agree with
this change. I might suggest that we add a new flag BG_BLOCK_EMPTY or
similar (which is really part of the FLEXBG feature so it doesn't affect
the existing uninit_groups code) that indicates that the block bitmap
contains NO allocated blocks, so that the kernel can know immediately
when reconstructing the bitmap that there are no bitmaps or itable in
that group (i.e. the bitmap is all zero).
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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
