On Apr 23, 2008 16:05 -0500, Jose R. Santos wrote: > On Wed, 23 Apr 2008 14:39:55 -0600 > Andreas Dilger <adilger@xxxxxxx> wrote: > > 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? It could mean either... What is important is if that is useful it should be done before FLEXBG goes into the field. The kernel can already determine somewhat efficiently whether a group has sb or gdt backups, though it can't hurt to flag this also. What seems to be quite difficult is to know in the presence of FLEXBG whether a group has an itable or bitmap in it. I'd HOPE (and I believe this is what Ted's recent patch did) is that any group which is being used to store flexbg data will have an initialized block bitmap in it, because it is "non-standard". What is more tricky is if a group has BLOCK_UNINIT and/or INODE_UNINIT set what should happen when that group's block bitmap is initialized. Should it assume there is a block + inode bitmap and an itable, or is it enough to check its own group descriptor to determine if the bitmap and itable are not in the group itself. Maybe I'm being paranoid, and we don't need the flag(s), but better to think the issues through now and decide we don't need them, than to decide later that we do. 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
