On Sat, Oct 09, 2010 at 04:08:54AM -0400, Christoph Hellwig wrote: > __inode_add_to_list does two things that aren't related. First it adds > the inode to the s_inodes list in the superblock, and second it optionally > adds the inode to the inode hash. Now that these don't even share the > same lock there is no need to keeps this functionally together. Split > out an add_to_inode_hash helper from __insert_inode_hash to add an inode > to a pre-calculated hash bucket for use by the various iget version, and > a inode_add_to_sb_list helper from __inode_add_to_list to just add an > inode to the per-sb list. The inode.c-internal callers of > __inode_add_to_list are converted to a sequence of inode_add_to_sb_list > and __insert_inode_hash (if needed), and the only use of inode_add_to_list > in XFS is replaced with a call to inode_add_to_sb_list and insert_inode_hash. The only reason XFS hashed the inodes was to avoid problems in the generic code that checked for unhashed inodes during clear_inode(). The evict() changeover moved that unhashed check into generic_drop_inode(), which the filesystem can override. Hence if you add a ->drop_inode() method for XFS that just checks the link count, we can avoid haÑhing the inodes altogether for XFS. I can add another patch on top of this one to do that if you want... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
