From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [PATCH 6/6] writeback: limit write_cache_pages integrity scanning to current EOF Date: Tue, 8 Jun 2010 16:59:22 +1000 Message-ID: <20100608065922.GA7869@dastard> References: <1275957487-23633-1-git-send-email-david@fromorbit.com> <1275957487-23633-7-git-send-email-david@fromorbit.com> <20100608053831.GR26335@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org To: Nick Piggin Return-path: Received: from bld-mail17.adl2.internode.on.net ([150.101.137.102]:37965 "EHLO mail.internode.on.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753327Ab0FHG7g (ORCPT ); Tue, 8 Jun 2010 02:59:36 -0400 Content-Disposition: inline In-Reply-To: <20100608053831.GR26335@laptop> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jun 08, 2010 at 03:38:31PM +1000, Nick Piggin wrote: > On Tue, Jun 08, 2010 at 10:38:07AM +1000, Dave Chinner wrote: > > From: Dave Chinner > > > > sync can currently take a really long time if a concurrent writer is > > extending a file. The problem is that the dirty pages on the address > > space grow in the same direction as write_cache_pages scans, so if > > the writer keeps ahead of writeback, the writeback will not > > terminate until the writer stops adding dirty pages. > > > > For a data integrity sync, we only need to write the pages dirty at > > the time we start the writeback, so we can stop scanning once we get > > to the page that was at the end of the file at the time the scan > > started. > > > > This will prevent operations like copying a large file preventing > > sync from completing as it will not write back pages that were > > dirtied after the sync was started. This does not impact the > > existing integrity guarantees, as any dirty page (old or new) > > within the EOF range at the start of the scan will still be > > captured. > > > > This patch will not prevent sync from blocking on large writes into > > holes. > > The writes don't have to be into holes to cause this starvation > problem, do they? No, they don't. > > That requires more complex intervention while this patch only > > addresses the common append-case of this sync holdoff. > > Jan's tagging patch looks pretty good to me and isn't so complex. > I think we should just take that. I don't care which one we take as long as it is actually tested by more than the submitter and we get everything in for 2.6.35... Cheers, Dave. -- Dave Chinner david@fromorbit.com