Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760802AbXHEUYv (ORCPT ); Sun, 5 Aug 2007 16:24:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753105AbXHEUYm (ORCPT ); Sun, 5 Aug 2007 16:24:42 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:47672 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752755AbXHEUYl (ORCPT ); Sun, 5 Aug 2007 16:24:41 -0400 Subject: Re: [patch] implement smarter atime updates support From: Arjan van de Ven To: Alan Cox Cc: Ingo Molnar , Linus Torvalds , Jakob Oestergaard , Jeff Garzik , miklos@szeredi.hu, akpm@linux-foundation.org, neilb@suse.de, dgc@sgi.com, tomoki.sekiyama.qu@hitachi.com, Peter Zijlstra , linux-mm@kvack.org, Linux Kernel Mailing List , nikita@clusterfs.com, trond.myklebust@fys.uio.no, yingchao.zhou@gmail.com, richard@rsk.demon.co.uk, david@lang.hm In-Reply-To: <20070805210446.57aa66f6@the-village.bc.nu> References: <20070804163733.GA31001@elte.hu> <46B4C0A8.1000902@garzik.org> <20070805102021.GA4246@unthought.net> <46B5A996.5060006@garzik.org> <20070805105850.GC4246@unthought.net> <20070805124648.GA21173@elte.hu> <20070805190928.GA17433@elte.hu> <20070805192226.GA20234@elte.hu> <1186343582.25667.3.camel@laptopd505.fenrus.org> <20070805210446.57aa66f6@the-village.bc.nu> Content-Type: text/plain Organization: Intel International BV Date: Sun, 05 Aug 2007 13:22:36 -0700 Message-Id: <1186345356.25667.7.camel@laptopd505.fenrus.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-2.fc7) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1468 Lines: 36 On Sun, 2007-08-05 at 21:04 +0100, Alan Cox wrote: > O> you might want to add > > > > /* > > * if the inode is dirty already, do the atime update since > > * we'll be doing the disk IO anyway to clean the inode. > > */ > > if (inode->i_state & I_DIRTY) > > return 1; > > This makes the actual result somewhat less predictable. Is that wise ? > Right now its clear what happens based on what user sequence of events > and that this is easily repeatable. I can see the repeatability argument; on the flipside, having a system of "opportunistic atime", eg as good as you can go cheaply, but with minimum guarantees has some attraction as well. For example one could imagine a system where the inode gets it's atime updated anyway, just not flagged for writing back to disk. If it later undergoes some event that would cause it to go to disk, it gets preserved... otoh that's even more unpredictable since VM pressure could drop this update early. For the dirty case, such drawbacks don't exist; it's just one more step of "when we can cheaply". -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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/