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
