AFAIK it's the very rare program indeed that relies on atime, and using
noatime is safe virtually everywhere.
The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:
mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.
Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.
noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard
relatime, saving every write on a flash/SSD is good):
Submitted by Jeremy on August 7, 2007 - 11:26am
In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified." Ingo Molnar stressed the significance of fixing this performance issue, "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." He submitted some patches to improve relatime, and noted about atime:
"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!'"
There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:
There exist applications that will move files off to a secondary storage if they haven't been accessed for a certain time period. Obviously, they need the atime.
Other than that, I don't see much use for this (anymore), especially as file managers these days have a tendency to open files to generate previews, therefore modifiying the atime just while browsing a directory.
I always mount with noatime these days.
answered Jul 29 '09 at 11:09