From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753317Ab1LSOiQ (ORCPT ); Mon, 19 Dec 2011 09:38:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54667 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751229Ab1LSOiN (ORCPT ); Mon, 19 Dec 2011 09:38:13 -0500 Subject: Re: [PATCH 3/4] vfs: count unlinked inodes From: Steven Whitehouse To: Al Viro Cc: Miklos Szeredi , hch@infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, jack@suse.cz, akpm@linux-foundation.org, toshi.okajima@jp.fujitsu.com, mszeredi@suse.cz In-Reply-To: <20111217073604.GA31872@ZenIV.linux.org.uk> References: <1321873893-4544-1-git-send-email-miklos@szeredi.hu> <1321873893-4544-4-git-send-email-miklos@szeredi.hu> <20111217073604.GA31872@ZenIV.linux.org.uk> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat UK Ltd Date: Mon, 19 Dec 2011 14:38:42 +0000 Message-ID: <1324305522.2723.51.camel@menhir> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Sat, 2011-12-17 at 07:36 +0000, Al Viro wrote: > On Mon, Nov 21, 2011 at 12:11:32PM +0100, Miklos Szeredi wrote: > > @@ -241,6 +242,11 @@ void __destroy_inode(struct inode *inode) > > BUG_ON(inode_has_buffers(inode)); > > security_inode_free(inode); > > fsnotify_inode_delete(inode); > > + if (!inode->i_nlink) { > > + WARN_ON(atomic_long_read(&inode->i_sb->s_remove_count) == 0); > > + atomic_long_dec(&inode->i_sb->s_remove_count); > > + } > > Umm... That relies on ->destroy_inode() doing nothing stupid; granted, > all work on actual file removal should've been done in ->evice_inode() > leaving only (RCU'd) freeing of in-core, but there are odd ones that > do strange things in ->destroy_inode() and I'm not sure that it's not > a Yet Another Remount Race(tm). OTOH, it's clearly not worse than what > we used to have; just something to keep in mind for future work. > GFS2 is one of those cases. The issue is that when we enter ->evict_inode() with i_nlink 0, we do not know whether any other node still has the inode open. If it does, then we do not deallocate it in ->evict_inode() but instead just forget about it, just as if i_nlink was > 0 leaving the remaining opener(s) to do the deallocation later, Steve.