On Tue, 11 Dec 2007 16:15:28 -0700 Andreas Dilger <adilger@xxxxxxx> wrote: > On Dec 11, 2007 10:08 -0600, Jose R. Santos wrote: > > > I'd think being able to avoid the divide for every inode allocation is more > > > important than 8 bits in the superblock. > > > > We already avoid the divide since what we store in the sbi IS the bits > > which are calculated at mount time for each fs. Base on the other > > fields in the super block struct, I decided to put explicit size of the > > flexbg in the super block. The kernel code can decide how best to use > > that number which in this case its used to calculate the number of bits > > in order to avoid doing divides. > > > > So this is really a styling issue in how to record data in the super > > block. The only technical issue with this is whether it's important to > > save those extra 8 bits in the super block struct. > > Well, if it is stored in the superblock as a non-power-of-two value, then > there always exists the possibility that it is set incorrectly (maybe by > a version of mke2fs that doesn't verify this) and the code will not do the > right thing. Storing it in bits (as is done with e.g. s_log_block_size and > s_log_frag_size) ensures there is no possibility of a value that isn't a > power-of-two. While I don't necessary buy the mke2fs example (the only patch that set this already checks for power-of-two), you are right about the possibility of being set incorrectly. I will change it to store the bits in the next release which I'll do after I fix the resize2fs issues since this will require changes to the e2fsprogs as well. 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. > 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
