On Sun, 10 Feb 2008 23:33:51 -0500 Theodore Tso <tytso@xxxxxxx> wrote: > On Fri, Feb 08, 2008 at 11:37:40AM -0600, Jose R. Santos wrote: > > > > #define EXT2_BG_INODE_UNINIT 0x0001 /* Inode table/bitmap not initialized */ > > > > #define EXT2_BG_BLOCK_UNINIT 0x0002 /* Block bitmap not initialized */ > > > > +#define EXT2_BG_FLEX_METADATA 0x0004 /* FLEX_BG block group contains meta-data */ > > > > > > Hrm, I thought I had reserved that value in the uninit_groups patch? > > > +#define EXT3_BG_INODE_ZEROED 0x0004 /* On-disk itable initialized to zero */ > > > > I may have been, I just based the patch on the next branch as Ted had > > ask for new e2fsprog patches. The uninit group patch was not part of > > the next branch when I pulled. > > Yes, but whenever you start reserving code points that impact the > on-disk format, you need to be careful and coordinate. Exactly is the > purpose of this flag, and why is it here? Will fix. > And I don't see any patch in the kernel patch queue that uses this > flag. Is this intended for internal use inside e2fsprogs? If so, > this might not be the best place for it..... > > - Ted Currently, this is only used in e2fsprogs to determine which groups to avoid when setting the EXT2_BG_BLOCK_UNINIT. It will be use on ext4_init_block_bitmap() to return the right number of free block when a block group does not have any meta-data in it. Eventually, it would be nice to accurately and efficiently calculate the number of meta data block used for a flexbg and be able to have these block groups uninitialized as well. This flag will be use to determine which groups need to have their meta data block usage calculated. -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
