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 -- 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
