Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937232AbXHIAzO (ORCPT ); Wed, 8 Aug 2007 20:55:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763424AbXHIAzA (ORCPT ); Wed, 8 Aug 2007 20:55:00 -0400 Received: from dvhart.com ([64.146.134.43]:48001 "EHLO dvhart.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763806AbXHIAy7 (ORCPT ); Wed, 8 Aug 2007 20:54:59 -0400 Message-ID: <46BA65E1.8010704@mbligh.org> Date: Wed, 08 Aug 2007 17:54:57 -0700 From: Martin Bligh User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Andrew Morton Cc: Christoph Hellwig , J??rn Engel , Ingo Molnar , Jeff Garzik , Linus Torvalds , Peter Zijlstra , linux-mm@kvack.org, Linux Kernel Mailing List , miklos@szeredi.hu, neilb@suse.de, dgc@sgi.com, tomoki.sekiyama.qu@hitachi.com, nikita@clusterfs.com, trond.myklebust@fys.uio.no, yingchao.zhou@gmail.com, richard@rsk.demon.co.uk, david@lang.hm Subject: Re: [PATCH 00/23] per device dirty throttling -v8 References: <20070804070737.GA940@elte.hu> <20070804103347.GA1956@elte.hu> <20070804163733.GA31001@elte.hu> <46B4C0A8.1000902@garzik.org> <20070804191205.GA24723@lazybastard.org> <20070804192130.GA25346@elte.hu> <20070804192615.GA25600@lazybastard.org> <20070804194259.GA25753@lazybastard.org> <20070805203602.GB25107@infradead.org> <46BA3137.3020701@mbligh.org> <20070808142146.c85ab8d7.akpm@linux-foundation.org> In-Reply-To: <20070808142146.c85ab8d7.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1056 Lines: 27 Andrew Morton wrote: > On Wed, 08 Aug 2007 14:10:15 -0700 > "Martin J. Bligh" wrote: > >> Why isn't this easily fixable by just adding an additional dirty >> flag that says atime has changed? Then we only cause a write >> when we remove the inode from the inode cache, if only atime >> is updated. > > I think that could be made to work, and it would fix the performance > issue. > > It is a behaviour change. At present ext3 (for example) commits everything > every five seconds. After a change like this, a crash+recovery could cause > a file's atime to go backwards by an arbitrarily large time interval - it > could easily be months. A second pdflush / workqueue at a slower rate would alleviate that. Yes, it's a semantic change ... but only in an incredibly small corner-case ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/