On Sun, Oct 24, 2010 at 07:40:58PM +0200, Christoph Hellwig wrote: > - writeback_single_inode skips all list manipulations for I_FREEING, > but not for I_WILL_FREE. We don't care about which list an > I_WILL_FREE inode is on, because we will remove it from the list > a little bit later. > - __mark_inode_dirty skips I_FREEING inodes but not I_WILL_FREE > inodes. This only matters for filesystem that re-dirty the inode > during writeback and then use the I_DIRTY flags inside ->evict_inode. > The formers is done by XFS, but it uses it's internal state to flush > the inode. I could not find any filesystem that looks at I_DIRTY > inside ->evict_inode either. > > Besides cleaning up the code removing I_WILL_FREE will allow us to > avoid one i_lock roundtrip once inode_lock is split and keep iput_final > more logic. This includes removing the __remove_inode_hash call in > iput_final, given that we never drop the protection from lookups now > that I_FREEING is set earlier. The thing is, the code is really brittle in that area. What we rely upon is * due to sync_filesystem() done just before there won't be anything dirty during invalidate_inodes() (OK, evict_inodes() now) run. * for final iput done during ->put_super() we won't redirty the inode. Note that we used to loop in write_one_inode() until the sucker got clean. Not anymore (since 2002 or so). * XFS does redirty, but then it does explicit write of those guys itself (from ->put_super()). Let's leave that alone for now; I remember quite well how much PITA has that area caused us in the past (my fuckup in 2.4.15, etc.) and I'd rather not mix revisiting that fun place with other non-trivial work. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
