On Fri, Apr 25, 2008 at 02:10:26PM -0600, Andreas Dilger wrote: > 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". Correct. If there are *any* blocks allocated other than the block's own metadata, BLOCK_UNINIT will never be set. And that's precisely to avoid the tricky case described in your next paragraph: > 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. In the kernel, it should be enough only to check bg_inode_bitmp, bg_block_bitmap, and bg_inode_table to construct the block bitmap. The point was to keep things simple. The cost of doing this is that you will end up needing to initialize the block bitmaps for every an extra 1 out of every flex_bg_size block groups, but that's not a major cost. It also means that BLOCK_UNINIT and BLOCK_BG_EMPTY as defined by Andreas are the same thing. This was a Keep It Simple, Stupid design point; I don't think the complexity is worth it. If someone wants to convince me that the benefits of forcing the kernel and e2fsck pass5 to paw through all of the block group descriptors to construct the block bitmap outweighs the costs (and more importantly, volunteers to write the code :-), I'm willing to be convinced otherwise.... - Ted -- 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
