From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 7/58] new helper: end_writeback() Date: Wed, 9 Jun 2010 14:20:18 +0100 Message-ID: <20100609132018.GZ31073@ZenIV.linux.org.uk> References: <20100609130216.GB3861@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:34381 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753097Ab0FINUT (ORCPT ); Wed, 9 Jun 2010 09:20:19 -0400 Content-Disposition: inline In-Reply-To: <20100609130216.GB3861@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jun 09, 2010 at 09:02:16AM -0400, Christoph Hellwig wrote: > On Tue, Jun 08, 2010 at 11:16:02PM +0100, Al Viro wrote: > > > > Essentially, the minimal variant of ->evict_inode(). It's > > a trimmed-down clear_inode(), sans any fs callbacks. Once > > it returns we know that no async writeback will be happening; > > every ->evict_inode() instance should do that once and do that > > before doing anything ->write_inode() could interfere with > > (e.g. freeing the on-disk inode). > > Naming seems a bit unfortunate - this really sounds like something > in page writeback. In fact I'd almost bet we had a function with > that name there in the past. > > Care to slap an inode_ prefix on it? Ehh... I'd been tempted to call it end_async or something like that. I'm not particulary fond of the name; any better suggestions are welcome. The point of what's being done in that function is that it acts as a barrier; "wait for async activity to run down; new one won't be started since it's already marked I_FREEING".