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
.
If you are concerned about using noatime
in general, you could devote a separate filesystem for your mongoDB stuff, and mount only that filesystem with noatime
.
EDIT
I found an interesting blog at kerneltrap.org that quotes some discussions between Linux developers (Linus Torvalds, Ingo Molnar, Alan Cox, and others) on the topic of atime
. In Ingo's second email, he says this:
... i've got no real complaint about
ext3 - with the obligatory qualification that "noatime,nodiratime" in
/etc/fstab is a must. This speeds up things very visibly - especially
when lots of files are accessed. It's kind of weird that every Linux
desktop and server is hurt by a noticeable IO performance slowdown due
to the constant atime updates, while there's just two real users of it:
tmpwatch [which can be configured to use ctime so it's not a big issue]
and some backup tools. (Ok, and mail-notify too i guess.) Out of tens of
thousands of applications. So for most file workloads we give Windows a
20%-30% performance edge, for almost nothing.