On Fri, Nov 07, 2008 at 07:57:18PM +0530, Aneesh Kumar K.V wrote: > On Fri, Nov 07, 2008 at 08:52:22AM -0500, Theodore Tso wrote: > > On Fri, Nov 07, 2008 at 11:22:56AM +0100, Frédéric Bohé wrote: > > > From: Frederic Bohe <frederic.bohe@xxxxxxxx> > > > > > > Block group's checksum need to be re-calculated during the > > > initialization of an UNINIT'd group. This fix a race when several > > > threads try to allocate a new inode in an UNINIT'd group. > > > > This patch looks sane, and so I'll accept it, but there's a higher > > order hiding here ---- why are we initializing the block bitmap in > > ext4_new_inode()? Sure, *most* of the time where we create a new > > inode, we'll be needing to allocate a new block, but sometimes we > > won't (i.e., when creating a symlink, device file, socket, or a > > zero-length regular file). > > Because when we clear the uninitt_bg flag the kernel expect the block > bitmap to be correctly indicate blocks containing block > bitmap and inode bitmap as used. If mke2fs didn't do that we would > need to do the same when we remove the uninit_bg flag. We have separate flags inidicating whether the block allocation bitmap and inode allocation bitmaps are initialized or not, EXT4_BG_BLOCK_UNINIT, and EXT4_BG_INODE_UNINIT, respectively. So what I am proposing is to not initialize the block bitmap in ext4_new_inode(), and not to clear the EXT4_BG_BLOCK_UNINIT flag, either. - 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
