On Wed, 23 Apr 2008 14:39:55 -0600
Andreas Dilger <adilger@xxxxxxx> wrote:
> 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?
Thanks for catching.
> > @@ -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).
I originally had a similar idea but was vetoed because there was no
kernel user on the flag. The flag that I used was set if the block
group had meta-data as opposed to just being empty since there are still
block groups out there that can have no meta-data but still have bgd or
backup super blocks. Would BG_BLOCK_EMPTY mean no bitmaps/inode tables
or does it imply completely empty block group?
> 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
-JRS
--
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
