From: "Jose R. Santos" <jrs@us.ibm.com>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation
 for FLEX_BG
Date: Wed, 23 Apr 2008 16:05:18 -0500
Message-ID: <20080423160518.5c7fad2e@gara>
References: <1208868379-17580-1-git-send-email-tytso@mit.edu>
	<1208868379-17580-2-git-send-email-tytso@mit.edu>
	<1208868379-17580-3-git-send-email-tytso@mit.edu>
	<20080423203955.GH2775@webber.adilger.int>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "Theodore Ts'o" <tytso@mit.edu>, linux-ext4@vger.kernel.org,
	Valerie Clement <valerie.clement@bull.net>
To: Andreas Dilger <adilger@sun.com>
In-Reply-To: <20080423203955.GH2775@webber.adilger.int>
Sender: linux-ext4-owner@vger.kernel.org

On Wed, 23 Apr 2008 14:39:55 -0600
Andreas Dilger <adilger@sun.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-JRS