From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank van Maarseveen Subject: Re: [RFC] [PATCH] Relative lazy atime Date: Thu, 10 Aug 2006 13:34:49 +0200 Message-ID: <20060810113449.GA7627@janus> References: <20060805122537.GA23239@lst.de> <1154797123.12108.6.camel@kleikamp.austin.ibm.com> <1154797475.3054.79.camel@laptopd505.fenrus.org> <20060805183609.GA7564@tuatara.stupidest.org> <20060805222247.GQ29686@ca-server1.us.oracle.com> <20060806030147.GG4379@parisc-linux.org> <20060809063947.GA13474@goober> <20060809122134.GF27863@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Valerie Henson , Matthew Wilcox , dean gaudet , David Lang , Mark Fasheh , Chris Wedgwood , Arjan van de Ven , Dave Kleikamp , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Akkana Peck , Jesse Barnes , jsipek@cs.sunysb.edu, Al Viro Return-path: Received: from frankvm.xs4all.nl ([80.126.170.174]:50828 "EHLO janus.localdomain") by vger.kernel.org with ESMTP id S1161177AbWHJLeu convert rfc822-to-8bit (ORCPT ); Thu, 10 Aug 2006 07:34:50 -0400 To: =?iso-8859-15?Q?J=F6rn?= Engel Content-Disposition: inline In-Reply-To: <20060809122134.GF27863@wohnheim.fh-wedel.de> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Aug 09, 2006 at 02:21:34PM +0200, J=F6rn Engel wrote: > At the risk of stating the obvious, let me try to explain what each > method does: >=20 > 1. standard > Every read access to a file/directory causes an atime update. >=20 > 2. nodiratime > Every read access to a non-directory causes an atime update. >=20 > 3. lazy atime > The first read access to a file/directory causes an atime update. >=20 > 4. noatime > No read access to a file/directory causes an atime update. 5. lazy atime writeout To reduce the pain of a fully functional atime only flush "atime-dirty" inodes when the on-disk/in-core atime difference becomes big enough (e.g. by maintaining an "atime dirtyness" level for the in-core inode). I haven't seen anyone mentioning it but properly written cleanup progra= ms for /tmp et.al. do depend on atimes. When a system crashes after a long time then (3) and (4) will probably cause /tmp to be wiped out because at the next boot all atimes will be really old. --=20 =46rank - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html