On Thu, 13 Dec 2007 15:58:57 -0700 Andreas Dilger <adilger@xxxxxxx> wrote: > On Dec 13, 2007 09:51 -0600, Jose R. Santos wrote: > > Now, storing the bits only guaranties that the flexbg size is always a > > power-of-two and does not guarantee that the super block flexbg size > > represents the actual meta-data grouping on disk. For this we need to > > verify that the bitmap offsets match what the super block reports. It > > may be an unlikely scenario, but it may be worth it to check this as > > well at mount time. > > I'm not sure what you mean... Isn't the flexbg size just a count of > the number of block groups? If it is always a power of two, and the > groups per metabg is always a power of two (it is) then they will > always be even multiples. What I mean is that if the value in the super block is corrupted and does not represent the actual flexbg size, the inode allocation will behave in weird unexpected ways. Just as we check that the bitmaps are within the block group range (when not using flexbg), we should probably sanity check the size of the flexbg as reported in the super block. Or do you believe the check is unnecessary? > Cheers, Andreas > -- > Andreas Dilger > Sr. Staff Engineer, Lustre Group > Sun Microsystems of Canada, 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
