From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: help with understanding evict inode functionality Date: Sat, 3 Oct 2015 23:01:36 -0700 Message-ID: <20151004060136.GA19017@infradead.org> References: <560E8D36.7010803@paragon-software.com> <788B0E19-4D87-4221-BB69-408E930A0227@netapp.com> <20151004022802.GB4442@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Kornievskaia, Olga" , Leonid Fedorenchik , "linux-fsdevel@vger.kernel.org" To: Theodore Ts'o Return-path: Received: from bombadil.infradead.org ([198.137.202.9]:60650 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751199AbbJDGB7 (ORCPT ); Sun, 4 Oct 2015 02:01:59 -0400 Content-Disposition: inline In-Reply-To: <20151004022802.GB4442@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.