On Fri, Sep 04, 2009 at 06:52:33AM -0600, Andreas Dilger wrote: > On Sep 04, 2009 14:19 +0530, Aneesh Kumar wrote: > > Ok i am running test with the below patch. It is more invasive in that it > > moves the need init flag check into load buddy. I guess we need to do that, > > otherwise we will be operating with stale buddy information when > > we have resize happening parallel. Also with the patch i posted before > > we still have issues as explained below > > > > a) we check for init flag we find it doesn't need an cache init > > b) we resize and mark the group in need for init > > c) in load buddy we look at the pageuptodate flag and find it uptodate > > and continue using the old buddy cache information. > > Why not have the resize code do the update of the buddy bitmap also? > When we were just using the block bitmap for allocation the resize > code would clear the bits in the bitmap just like deleting a file, > so that it was totally coherent with any other bitmap user. Having > the resize code do the same with the buddy (instead of only marking > it stale and leaving it for another process to refresh) should avoid > the race condition entirely. > We have EXT4_GROUP_INFO_NEED_INIT_BIT used at mutliple places. So having ext4_mb_load_buddy check for EXT4_GROUP_INFO_NEED_INIT_BIT flag make sense. It also allows us to consolidate the group init in one location. Another advantage is, with ext4_mb_load_buddy checking for EXT4_GROUP_INFO_NEED_INIT_BIT flag, we don't do reinit the buddy cache each time we add few blocks to the group. -aneesh -- 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
