Re: Disabling atime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, but the system should have sensible defaults 
that suit most people, and be able to be changed where appropriate for 
the minority.

The minority here is having atime, hardly anyone ever uses it compared to 
the cost of having it. It's easy to reenable it for the few who really 
find it useful and want to pay for it.

I've disabled atime on all filesystems on all my machines for well over 5 
years, pretty much as the first step after install, and have never once 
run into an issue. (Ok, so I never use mutt, but probably most users 
don't use mutt and since it has workarounds this can't be a reason by 
itself to keep atime.) I've missed the functionality probably less than 
once a year, and that's as a developer/sysadmin too.

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

> 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, a huge amount for such a simple 
change. I'll bet most of the difficult kernel optimisations are winning 
less than that.

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.)

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.

Cheers,

Martin.

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux