Comments on: No atime in Hammer

By: john

john — Tue, 22 Dec 2015 09:56:48 +0000

That is a very nice article Rahul! It also explains why atime by default is a problem, so everyone should read at the first half of it.

By: Rahul

Rahul — Tue, 22 Dec 2015 05:21:43 +0000

Meanwhile it seems Linux has moved beyond "relatime" to "lazytime" (which unlike "relatime" is posix compliant).

By: john

john — Mon, 21 Dec 2015 15:37:10 +0000

You never answered this, “Why are you assuming the performance impact of atime on Hammer is “minuscle”? Your entire comment is based on this premise.”. Obviously there is a significant negative impact to using atime, otherwise why would the effort have been made to 1) allowing it to be selectable and 2) allow it to be off by default?

Defaults are supposed to be set to benefit the majority of the users out of the both.

Your rebuttal of “ditto” for the explanation that changing it is not hard is not really a good response. I am sure there are people that hate atime as much as you love it, and not because they are “inexperienced”.

By: Thomas

Thomas — Mon, 21 Dec 2015 14:27:34 +0000

Especially with SSDs being the future, for which Matt himself has proven atime/IO/hammer fine grained history/reblocking isn’t an issue, I see no sense in this.

By: Thomas

Thomas — Mon, 21 Dec 2015 14:23:47 +0000

John, the “problem” is that at least according to my experience there is seldom a need to switch it off. Most machines (servers) are single purpose boxes, of which only a small subset is eligible for atime tuning e.g. due to high IO load involving lots and lots of files, for the rest it probably doesn’t matter. When was the last time atime really was an issue on other kind of boxes/services loadwise, what is there to gain?

On the other hand:
“Atime is very useful” => if it weren’t we probably would have gotten rid of it long ago.
“its light to turn back on” => it’s “light” to turn it off if it (or resulting performance) really bothers you.
“There is *NOTHING* preventing these people from enabling atime.” => There’s nothing preventing people from turning it off.

Atime is a *feature* NOT a liability in the vast majority on cases. Changing the default really should be backed up by hard numbers IMHO. I’m totally with Marcus here.

Next thing you know is async being the new mount default option to squeeze a single digit percent performance increase you don’t need out of your machine.

By: john

john — Mon, 21 Dec 2015 13:24:38 +0000

@Marcus
“Atime is very useful” => debatable
“should not be turned off lightly” => it’s “light” to turn back on
“People who come to rely on it miss it dearly.” => There is *NOTHING* preventing these people from enabling atime. This is news about change in the *DEFAULT* setting. Atime is not being removed!

what’s the problem?

By: Marcus

Marcus — Sat, 19 Dec 2015 20:10:15 +0000

This is a bad decision unless it is a data-driven one. Atime is very useful and should not be turned off lightly. If you don’t use atime regularly, it’s probably because you are not experienced in how useful it is. People who come to rely on it miss it dearly.

Where is the data behind this decision?

By: Rahul

Rahul — Thu, 17 Dec 2015 11:32:12 +0000

Linux has had “relatime” for many years now and it makes a lot of sense to me. atime is written only if the file was modified since the last atime update, or if sufficient time (1 day by default I think) has passed since the last atime update. This unbreaks mutt and similar programs, while keeping most of the performance gain of “noatime”. Why haven’t the BSD’s tried something similar?

By: Lars Schotte

Lars Schotte — Thu, 17 Dec 2015 08:39:10 +0000

Well, but you do not look every file if it is being pulled in or not. So for debugging purposes one could enable it for a while and disable after, because during normal operation you do not need atimes updated, because for the vast majority of files, you will never look at.

By: john

john — Mon, 14 Dec 2015 07:58:09 +0000

@Thomas

Why are you assuming the performance impact of atime on Hammer is “minuscle”? Your entire comment is based on this premise.

By: Justin Sherrill

Justin Sherrill — Sun, 13 Dec 2015 15:11:45 +0000

My perception – and this is picked up from conversation I’ve seen in IRC, not from direct benchmarks – is that atime modification makes a more significant difference than people expect. Meaning more people gain than lose.

By: Thomas

Thomas — Sun, 13 Dec 2015 12:32:50 +0000

I’m always a little sad when I see operating systems, distributions, filesystems default to noatime. Having atime around and enabled is really useful in day to day operations, e.g. when debugging stuff to see if config files are “pulled in” or when certain data hasn’t been used for a while and can possible be deleted or moved elsewhere. IMHO this really shouldn’t be disabled by default – most systems do not need the minuscle gains in performance offered by switching this off. Systems that profit from disabled atime in a significant way, e.g. mail/www/proxy servers, can always be tuned within mere minutes, for most other systems having atime switchted to or defaulting to off is really of no practical benefit.