I am setting up a mongoDB replica set and one of the first things I am suppose to do is turn off atime on the file system. After researching this a bit, I am not opposed to doing this, but I have to ask, what uses atime? I have searched the interwebs and found very little in the way of "this applciaiton or this process uses atime and you would be stupid if you turned it off" kinds of warnings, but being a paranoid person by nature, I have to wonder.
So, what uses atime and if I turn it off, what could break?
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 withnoatime
on all filesystems, and I can't recall ever having seen any problems attributable tonoatime
.If you are concerned about using
noatime
in general, you could devote a separate filesystem for your mongoDB stuff, and mount only that filesystem withnoatime
.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:Tools that poll for file usage such as temporary file cleaners use it. You can get around this on some filesystems and OSes by using
relatime
instead, which only updates the atime after a certain duration has passed since it was last updated.You could also create a seperate mount point for your mongoDB replica set. You can then set the noatime paramtere on that mountpoint only without affecting any other programs.
As a follow up here,
relatime
was made the default in the kernel in 2.6.30 which was released around the March 2009 time frame. That means that the gains you see from noatime settings will be less on any modern kernel.It is still a recommendation because there is still a performance gain to be had for MongoDB, but as long as you are on a reasonably current kernel version it is not as essential as it once was.
Also , in addition to the software mentioned here, I have also seen atime used by backup tools.
I'd just like to emphasise a point @Steven Monday - use a separate filesystem.
For a database this is always a good option and gives you a lot more flexibility in tuning database performance at the minor inconvenience of an extra mount point to manage. Usually will give you more options for snapshotting the database for backups too (even more handy in cases where you can snapshot & backup the replica instead of the master)