From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 3/7] writeback: Move I_DIRTY_PAGES handling Date: Mon, 30 Apr 2012 10:41:38 -0400 Message-ID: <20120430144138.GD10964@infradead.org> References: <1332284191-21076-1-git-send-email-jack@suse.cz> <1332284191-21076-4-git-send-email-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Wu Fengguang , Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from 173-166-109-252-newengland.hfc.comcastbusiness.net ([173.166.109.252]:57088 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754861Ab2D3Olj (ORCPT ); Mon, 30 Apr 2012 10:41:39 -0400 Content-Disposition: inline In-Reply-To: <1332284191-21076-4-git-send-email-jack@suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Mar 20, 2012 at 11:56:27PM +0100, Jan Kara wrote: > Instead of clearing I_DIRTY_PAGES and resetting it when we didn't succeed in > writing them all, just clear the bit only when we succeeded writing all the > pages. We also move the clearing of the bit close to other i_state handling to > separate it from writeback list handling. This is desirable because list > handling will differ for flusher thread and other writeback_single_inode() > callers in future. No filesystem plays any tricks with I_DIRTY_PAGES (like > checking it in ->writepages or ->write_inode implementation) so this movement > is safe. Looks good to me, Reviewed-by: Christoph Hellwig In addition to this cleanup I wonder if we could go further and just kill I_DIRTY_PAGES off. I can't see any value add over using mapping_tagged(mapping, PAGECACHE_TAG_DIRTY), which has the big benefit of beeing managed transparently by the pagecache radix tree.