Hammer now defaults to ‘noatime’, meaning the date and time of last access are not updated on every file action. Note that creation and modification date and time are still recorded. This will help with speed and disk activity.
This may cause a problem with any software expecting this to change – mutt, possibly? We will find out. This change was done after the 4.4 branch, so it’s not in the current release of DragonFly.
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.
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.
@Thomas
Why are you assuming the performance impact of atime on Hammer is “minuscle”? Your entire comment is based on this premise.
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.
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?
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?
@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?
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.
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.
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”.
Meanwhile it seems Linux has moved beyond “relatime” to “lazytime” (which unlike “relatime” is posix compliant).
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.