From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 4/4] fs: kill I_WILL_FREE Date: Tue, 26 Oct 2010 02:28:49 +0100 Message-ID: <20101026012849.GW19804@ZenIV.linux.org.uk> References: <20101024174024.GA2718@lst.de> <20101024174058.GD2718@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:39172 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753384Ab0JZB2u (ORCPT ); Mon, 25 Oct 2010 21:28:50 -0400 Content-Disposition: inline In-Reply-To: <20101024174058.GD2718@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Oct 24, 2010 at 07:40:58PM +0200, Christoph Hellwig wrote: > The I_WILL_FREE is currently set for inodes that we write out during > umount after dropping their last reference. It is handled equally > to I_FREEING in most places. The two execptions are: > > - writeback_single_inode skips all list manipulations for I_FREEING, > but not for I_WILL_FREE. We don't care about which list an > I_WILL_FREE inode is on, because we will remove it from the list > a little bit later. > - __mark_inode_dirty skips I_FREEING inodes but not I_WILL_FREE > inodes. This only matters for filesystem that re-dirty the inode > during writeback and then use the I_DIRTY flags inside ->evict_inode. > The formers is done by XFS, but it uses it's internal state to flush > the inode. I could not find any filesystem that looks at I_DIRTY > inside ->evict_inode either. > > Besides cleaning up the code removing I_WILL_FREE will allow us to > avoid one i_lock roundtrip once inode_lock is split and keep iput_final > more logic. This includes removing the __remove_inode_hash call in > iput_final, given that we never drop the protection from lookups now > that I_FREEING is set earlier. All except that one applied, exofs patch dropped, fixes folded, etc. Branch pushed in the same place...