Re: help with understanding evict inode functionality

[Christoph Hellwig <hch@infradead.org>]

On Sat, Oct 03, 2015 at 10:28:02PM -0400, Theodore Ts'o wrote:
> evict_inode() is what happens when i_nlink *and* i_icount hits zero.
> So it is only then that the local disk file system can actually
> release the inode and blocks associated with that inode.

That's not true.  Evict is called when we want to remove an inode
from memory.  i_count needs to be zero for that, but i_nlink doesn't
as we don't cache inodes forever.  When we drop i_count and it reaches
zero iput_final() is called, which decides depending on ->drop_inode
to either evict the inode or keep it on the LRU.

> Hence, there is no point trying to worry about what hapens if the file
> is reopened again, since the original inode is *gone*.  You could
> create a new file with the same file name, but none of the resources
> associated with the old inode need to be preserved for the newly
> created file.

And this isn't quite true either - this particular struct inode instance
might not come back, but we need to synchronize against a racing iget
if i_nlink wasn't zero.  This is done with the I_FREEING bit and the
bit wake up on __I_NEW.