On Fri, 3 Aug 2007 12:22:17 -0600 Andreas Dilger <adilger@xxxxxxxxxxxxx> wrote: > On Aug 02, 2007 23:00 -0500, Jose R. Santos wrote: > > Eventually, a more thorough check would restrict bitmaps and inode > > tables to be located at the beginning of a flex block group range. > > Since the super block does not currently know about the number of > > groups per flex group, this will do for now. > > As with regular block groups, it would probably be better to limit the > bitmaps and inode tables to anywhere inside the flexbg instead of the > start. That would allow, for example, INCOMPAT_FLEXBG to be enabled > on an existing filesystem and the metadata could be moved together as > space becomes available. This is something that would be simple to do if the ratio of block groups per flex group known to the filesystem itself. This implies adding another field to the super block as reliable way to obtain this information. The only thing keeping me from doing so is the uncertainty of backwards compatibility when changing the super block structure. I agree though that one of the requirements for this feature is more robust checking of the location of the bitmaps and inode tables within the flex group. Checking of the descriptor in flexbg become a little more complicated than in regular block groups because: 1. The block and inode bitmaps should be allocated a one big chunk for each flex group. 2. The block and inode bitmaps should be located in the first block group and the inode tables with in the first few groups of a flex group. 3. If the full range of bitmaps in not allocated contiguously, this means that bad blocks caused us to move a particular bitmap out and thus the bad block list should be checked to ensure that this was the case. If the above conditions are not met, this could point to possible corruption in the block descriptors. > Cheers, Andreas > -- > Andreas Dilger > Principal Software Engineer > Cluster File Systems, Inc. > -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
