Slashdot Mirror
Replacing Atime With Relatime in the Kernel
eldavojohn writes "Our friend Jeremy at the Kernal Trap has dug up some interesting criticism of atime from Linus Torvalds. As Linus submitted patches to improve relatime he noted: 'I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_.' And later severely beat atime about the head with a pointed stick: 'It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'" Well, I guess I can expect my Linux machine to become a little bit faster!"
Seriously. Many have recommended mounting filesystems with the "noatime" parameter if you don't need to know atime for many years now,
In the various BSD flavors you can mount volumes "noatime", which is generally safe and does a pretty good job of keeping things moving. If you really need atime updates you can always remount the volume, but frankly not many people use it from what I've seen (maybe tail -f?).
I read the internet for the articles.
And, for every file that is already cached and which we read from the cache ... do a write to the disk!'
Uh, why? Or rather, why not cache the atime update until disk usage is clear, THEN do the write, at least for already cached files?
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
Amazingly, standard Unix filesystems keep time of last access (atime), change of status (ctime), and file modification (mtime) but do not remember when the file was first created, which is something I have frequently wished for.
Intron: the portion of DNA which expresses nothing useful.
Deferred, maybe, but not for more than a few seconds, and when it happens it means more disk seeks...
It's long been standard practice to disable this on, eg, news/mail spools (anything with large numbers of read-mostly small files). The new plan of, if I understand correctly, only updating atime when the file is modified or if the new atime is more than 24 hours after the current atime should provide nearly the same functionality with practically none of the performance hit.
I did know, but not off the top of my head. I haven't mucked around at that level for quite a while now. Given that the summary seemed to imply that Linux did *not* have noatime support (which would be quite an odd thing indeed) I was not ready to challenge it until I actually read the article. Of course, it was a case of bad-summary-itis. (Again.)
As it so happens, TFA is an exercise in the danger of pulling from a conversation with little context to back it up. The only reason why they are discussing the matter is because a few programs like MUTT still use atime to synchronize their operation. If it weren't for MUTT (and presumably a few other unmentioned examples) I imagine that atime would be off by default by now.
Javascript + Nintendo DSi = DSiCade
I can't believe this is even an issue. I've been mounting everything noatime on my BSD systems for ages. The only thing I can think that it might possibly be used for are scripts that purge /tmp of files that haven't been accessed in a while. Even for that, ctime or mtime isn't a bad compromise.
Bit of trivia -- NTFS does the exact same thing with regards to access times. There's a registry entry to disable it buried somewhere deep that I don't remember at the moment, but if you're stuck on Windows it might be worth looking up to improve I/O performance.
If all you keep track of is attributes on an entire file basis, once a file is modified the create date no longer has any meaning.
However Mutt's use of atime simply is cheap enough that there's simply never been a reason to change it all the time most people have had atime updates on anyway. If it ain't broke, don't fix it.
You can disable it in a few different ways Once this is done, the Last Access Time attribute for newly created files will simply be their File Creation Time. Disabling Last Access Time may affect the operation of backup programs that use the Remote Storage service. YMMV
Or there's a registry key, which requires a reboot:
Cool! Amazing Toys.
for tracking which files are no longer used. That is why backup utilities such as tar have a --preserve-atime option to avoid updating atime during a backup. The proposed relatime option preserves the function of finding files no one uses anymore - for that purpose, 1 day resolution is fine. HSM systems depend on atime to know what to archive. Again, 1 day resolution is fine for that purpose.
and how is this any different from following all those guides out there that document how to use the windows registry to fine-tune performance? just because there is an option to change atime settings doesn't mean that it is a requirement to do so just to 'use linux on the desktop'
sorry, but i'm sick to death of these sorts of claims. actually try to use it before you start making claims such as this.