Disabling atime

[Ralf Corsepius]

On Fri, 2007-08-10 at 21:43 +0000, Martin Ebourne wrote:
> On Fri, 10 Aug 2007 15:09:11 +0200, Ralf Corsepius wrote:
> > On Fri, 2007-08-10 at 07:59 -0400, James Hubbard wrote:
> >> Just because it's a fundamental feature doesn't mean that it has to be
> >> used. Fundamentally, my CPU can run at 2GHz all of the time that
> >> doesn't mean that it should.  If 99% of the applications can do without
> >> it and probably 99% of the people can as well, why not go ahead and get
> >> disable it.
> > That's what people call "arrogance of the masses". Let's kill that 1%,
> > if 99% don't care!
> 
> Nobody's killing anybody,
You would - You would kill all applications which rely on atime.

Not that many applications will do so, but it's not hard to imagine one.

An example would be apps cleaning up/removing files based on atime.

> > <sarcasm>
> > It's the same argument why people argue against utf-8, work as root
> > (don't need uid/gids) and don't want SELinux?
> > 
> > Let's remove all of this from the kernel, single seat/single user
> > systems don't need all this at all.
> > </sarcasm>
> 
> No it's not, that's all completely unrelated.
Not? I disagree. 

You want a "fundamental feature, most users don't need/want" to be
disabled to gain performance. What I listed above is along the same
rationale.

> > A friend of mine experimented with atime/noatime yesterday:
> > These were his results:
> > Test case: A heavy weight compiler-job
> > new / old = .9465
> 
> That's over 5% performance improvement,
Well, whether 5% is "much" is arguable.

On many occasions, you won't even notice because it will get lost in the
jitter other factors impose.

Take out SELinux, gain "x %". Don't use kde, gain "x %". Use "lean mail
browser", gain "x %". Use gcc-<version>, gain another 20%. 
Don't have "big application" running in the background, gain "x %". Buy
a better harddisk, gain "x %".

>  a huge amount for such a simple 
> change. I'll bet most of the difficult kernel optimisations are winning 
> less than that.
Agreed, but with regard to compiler turn-around times, 5% is below the
jitter of other factors, such as differences in compilation speed
between different versions of GCC and differences in the impact of
compilation-flags being used in GCC.

> Now imagine the number of files touched on a boot, or logging into the 
> GUI and how much difference it makes there. (For hard numbers on the 
> 10,000s of files touched read Dave Jones's blog.)
Make /usr, /bin, /sbin etc. read-only, consider noatime on /home, atime
on /var, /tmp would be a reasonable approach.

> Personally I can't believe its taken this long for people to sit up and 
> take notice of atime which was pretty much a design failure from the 
> start.
Well, IIRC, noatime exists for circa a decade. Also, IIRC, this is not
the first time of such a proposal. I recall SuSE devs having recommended
it to me many years ago (ca. 2000) when facing "jerky" desktop behavior
at that time.

Ralf