All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank van Maarseveen <frankvm@frankvm.com>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: Valerie Henson <val_henson@linux.intel.com>,
	Matthew Wilcox <matthew@wil.cx>, dean gaudet <dean@arctic.org>,
	David Lang <dlang@digitalinsight.com>,
	Mark Fasheh <mark.fasheh@oracle.com>,
	Chris Wedgwood <cw@f00f.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Dave Kleikamp <shaggy@austin.ibm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Akkana Peck <akkana@shallowsky.com>,
	Jesse Barnes <jesse.barnes@intel.com>,
	jsipek@cs.sunysb.edu, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [RFC] [PATCH] Relative lazy atime
Date: Thu, 10 Aug 2006 13:34:49 +0200	[thread overview]
Message-ID: <20060810113449.GA7627@janus> (raw)
In-Reply-To: <20060809122134.GF27863@wohnheim.fh-wedel.de>

On Wed, Aug 09, 2006 at 02:21:34PM +0200, Jörn Engel wrote:
> At the risk of stating the obvious, let me try to explain what each
> method does:
> 
> 1. standard
> Every read access to a file/directory causes an atime update.
> 
> 2. nodiratime
> Every read access to a non-directory causes an atime update.
> 
> 3. lazy atime
> The first read access to a file/directory causes an atime update.
> 
> 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 programs
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.

-- 
Frank

WARNING: multiple messages have this Message-ID (diff)
From: Frank van Maarseveen <frankvm@frankvm.com>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: Valerie Henson <val_henson@linux.intel.com>,
	Matthew Wilcox <matthew@wil.cx>, dean gaudet <dean@arctic.org>,
	David Lang <dlang@digitalinsight.com>,
	Mark Fasheh <mark.fasheh@oracle.com>,
	Chris Wedgwood <cw@f00f.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Dave Kleikamp <shaggy@austin.ibm.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Akkana Peck <akkana@shallowsky.com>,
	Jesse Barnes <jesse.barnes@intel.com>,
	jsipek@cs.sunysb.edu, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [RFC] [PATCH] Relative lazy atime
Date: Thu, 10 Aug 2006 13:34:49 +0200	[thread overview]
Message-ID: <20060810113449.GA7627@janus> (raw)
In-Reply-To: <20060809122134.GF27863@wohnheim.fh-wedel.de>

On Wed, Aug 09, 2006 at 02:21:34PM +0200, Jörn Engel wrote:
> At the risk of stating the obvious, let me try to explain what each
> method does:
> 
> 1. standard
> Every read access to a file/directory causes an atime update.
> 
> 2. nodiratime
> Every read access to a non-directory causes an atime update.
> 
> 3. lazy atime
> The first read access to a file/directory causes an atime update.
> 
> 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 programs
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.

-- 
Frank
-
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

  parent reply	other threads:[~2006-08-10 11:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03  6:36 [RFC] [PATCH] Relative lazy atime Valerie Henson
2006-08-03 14:48 ` Matthew Wilcox
2006-08-05 12:25 ` Christoph Hellwig
2006-08-05 13:22   ` Arjan van de Ven
2006-08-09 14:03     ` Valerie Henson
2006-08-09 15:49       ` Erez Zadok
2006-08-10 12:27       ` Helge Hafting
2006-08-05 16:58   ` Dave Kleikamp
2006-08-05 17:04     ` Arjan van de Ven
2006-08-05 18:36       ` Chris Wedgwood
2006-08-05 22:22         ` Mark Fasheh
2006-08-05 23:06           ` David Lang
2006-08-05 23:28             ` dean gaudet
2006-08-06  0:11               ` Chris Wedgwood
2006-08-06  3:01               ` Matthew Wilcox
2006-08-09  6:39                 ` Valerie Henson
2006-08-09 12:21                   ` Jörn Engel
2006-08-09 12:21                     ` Jörn Engel
2006-08-09 12:58                     ` Dave Kleikamp
2006-08-09 12:58                       ` Dave Kleikamp
2006-08-10 11:34                     ` Frank van Maarseveen [this message]
2006-08-10 11:34                       ` Frank van Maarseveen
2006-08-10 17:28                   ` Bill Davidsen
2006-08-06  0:13             ` Mark Fasheh
     [not found] <6Gts4-6UM-1@gated-at.bofh.it>
     [not found] ` <6GxFs-4Tg-13@gated-at.bofh.it>
     [not found]   ` <6Gy8r-5Oh-11@gated-at.bofh.it>
     [not found]     ` <6Gze7-7oP-7@gated-at.bofh.it>
     [not found]       ` <6GCOJ-4fv-19@gated-at.bofh.it>
     [not found]         ` <6GDB1-5qX-3@gated-at.bofh.it>
     [not found]           ` <6GDKT-5Eb-37@gated-at.bofh.it>
     [not found]             ` <6GHbD-2hm-1@gated-at.bofh.it>
     [not found]               ` <6HQ3c-6Pf-9@gated-at.bofh.it>
     [not found]                 ` <6HVml-6DI-11@gated-at.bofh.it>
     [not found]                   ` <6Ih3l-5FP-1@gated-at.bofh.it>
2006-08-10 13:07                     ` Bodo Eggert
2006-08-10 13:07                       ` Bodo Eggert
  -- strict thread matches above, loose matches on Subject: below --
2006-08-03  6:29 Valerie Henson
2006-08-03  6:44 ` Josef Sipek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060810113449.GA7627@janus \
    --to=frankvm@frankvm.com \
    --cc=akkana@shallowsky.com \
    --cc=arjan@linux.intel.com \
    --cc=cw@f00f.org \
    --cc=dean@arctic.org \
    --cc=dlang@digitalinsight.com \
    --cc=hch@lst.de \
    --cc=jesse.barnes@intel.com \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=jsipek@cs.sunysb.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.fasheh@oracle.com \
    --cc=matthew@wil.cx \
    --cc=shaggy@austin.ibm.com \
    --cc=val_henson@linux.intel.com \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.