Re: help with understanding evict inode functionality

[Theodore Ts'o <tytso@mit.edu>]

On Fri, Oct 02, 2015 at 02:38:49PM +0000, Kornievskaia, Olga wrote:
> 
> Again a general question to the community about inodes and
> eviction. I was under the general impression that when the file is
> closed the inode sticks around just in case the file is reopened
> again. Then when resources are constrainted some background thread
> evicts unused inodes. Is that understanding correct?

I think you're confused about what evict_inode() does.  The i_count
field tracks how many in-memory references the inode has.  Each iput()
decrements i_count.  Once i_count goes to zero, there are no more open
file descriptors for that inode.

Then there is also i_nlink.  This is the number of directory entries
which point at the inode on disk.  When you unlink() a file, this
drops the i_nlink on the inode.  When i_nlink drops to zero, then the
inode is no longer referenced by any directory entry.  But, this
doesn't mean we can actually release the inode and the blocks
associated with the file --- Unix semantics is that you can have an
open file descriptor on an unlinked file, and when the last fd is
closed, only then does the inode get released.

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.

So by the time the file system's evict_inode() is called, the inode is
not coming back.  With apologies to Monty Python, the inode is no
more; it has ceased to be.  It's expired and gone to meet its
maker..... It is an ex-inode.  :-)

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.

Cheers,

						- Ted

P.S.  Things do get a little complicated with non-native Unix file
systems which don't obey Posix semantics, or if you are dealing with a
pre-NFSv4 protocol which quaintly assumes that you can have a
stateless networked file system protocol when a file system is
inherently stateful.  For more information, see:

http://serverfault.com/questions/267601/can-open-files-be-unlinked-on-nfs-mounted-volumes-while-applications-that-still