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