On Mon, 20 Oct 2008, Christoph Lameter wrote: > Miklos Szeredi wrote: > >>> Yes, but I'm not at all sure that calling remove_inode_buffers() or > >>> invalidate_mapping_pages() is OK on a live inode. They should be done > >>> after checking the refcount, just like prune_icache() does. > >> Dont we do the same on a truncate? > > > > Yes, with i_mutex and i_alloc_sem held. > > There is another call to invalidate_mapping_pages() in prune_icache (that is > where this code originates). No i_mutex and i_alloc. Only iprune_mutex held > and that seems to be for the protection of the list. So just checking > inode->i_count would do the trick? Yes, that's what I was saying. > > The big issue is dealing with umount. You could do something like > > grab_super() on sb before getting a ref on the inode/dentry. But I'm > > not sure this is a good idea. There must be a simpler way to achieve > > this.. > > Taking a lock on vfsmount_lock? But that would make dentry reclaim a pain. No, I mean simpler than having to do this two stage stuff. > We are only interested in the reclaim a dentry if its currently unused. If so > then why does unmount matter? Both unmount and reclaim will attempt to remove > the dentry. > > Have a look at get_dentries(). It takes the dcache_lock and checks the dentry > state. Either the entry is ignored or dget_locked() removes it from the lru. > If its off the LRU then it can no longer be reclaimed by umount. How is that better? You will still get busy inodes on umount. And anyway the dentry could be put back onto the LRU by somebody else between get_dentries() and kick_dentries(). So I don't even see how taking the dentry off the LRU helps _anything_. Miklos -- 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
