Re: [RFC] [PATCH] Relative lazy atime

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Tue, 8 August 2006 23:39:49 -0700, Valerie Henson wrote:
> On Sat, Aug 05, 2006 at 09:01:47PM -0600, Matthew Wilcox wrote:
> > On Sat, Aug 05, 2006 at 04:28:29PM -0700, dean gaudet wrote:
> > > you can work around mutt's silly dependancy on atime by configuring it 
> > > with --enable-buffy-size.  so far mutt is the only program i've discovered 
> > > which cares about atime.
> > 
> > For the shell, atime is the difference between 'you have mail' and 'you
> > have new mail'.
> > 
> > I still don't understand though, how much does this really buy us over
> > nodiratime?
> 
> Lazy atime buys us a reduction in writes over nodiratime for any
> workload which reads files, such as grep -r, a kernel compile, or
> backup software.  Do I misunderstand the question?

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.

In comparison, lazy atime will cause more atime updates for
directories and vastly fewer for non-directories.  Effectively atime
is turned into little more than a flag, stating whether the file was
ever read since the last write to it.  And it appears as if neither
mutt nor the shell use atime for more than this flagging purpose, so I
am rather fond of the idea.

Jörn

-- 
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories