If you have a newish install (~2008), you can use the relatime mount option. This is a good compromise for atime I think. From the kerneltrap discussion about implementing this new option:
"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."
This makes it so most of the applications that need atime will still work, but lessens the disk load -- so it is a compromise. This is the default with recent Ubuntu desktop distributions.
Regarding noatime and nodiratime:
If you are going noatime for files, I wonder if there is a reason not to use nodiratime in addition to noatime so you are not updating the access time on directories as well.
The other reason to keep atime enabled which wasn't mentioned is for auditing purposes. But since who accessed it is not kept and only when, it is probably not that useful for an audit trail.
All of these options can be found in 'man mount 8'.
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.
There are very little there are some applications that rely on this for example Mutt cannot determine if the folder has received new mail since last visited.
Generally I and others think that mounting noatime is a good idea.
the main disadvantage that hasn't been mentioned yet is that if you have a tmpreaper process (i.e. a program that deletes files in /tmp that haven't been accessed for a while), it could delete tmp files that are still in use.
relatime is a better option than noatime. it only updates atime if the file has been modified since the last atime update. this has obvious benefits for mail clients. it still doesn't fix the tmpreaper issue (a file may be read from /tmp for ages without being written to).
overall, the disadvantages are minor (non-existant except for a few special cases), and the performance benefit is significant.
Consider relatime:
If you have a newish install (~2008), you can use the relatime mount option. This is a good compromise for atime I think. From the kerneltrap discussion about implementing this new option:
This makes it so most of the applications that need atime will still work, but lessens the disk load -- so it is a compromise. This is the default with recent Ubuntu desktop distributions.
Regarding noatime and nodiratime:
If you are going noatime for files, I wonder if there is a reason not to use nodiratime in addition to noatime so you are not updating the access time on directories as well.
The other reason to keep atime enabled which wasn't mentioned is for auditing purposes. But since who accessed it is not kept and only when, it is probably not that useful for an audit trail.
All of these options can be found in 'man mount 8'.
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.
There are very little there are some applications that rely on this for example Mutt cannot determine if the folder has received new mail since last visited.
Generally I and others think that mounting noatime is a good idea.
the main disadvantage that hasn't been mentioned yet is that if you have a tmpreaper process (i.e. a program that deletes files in /tmp that haven't been accessed for a while), it could delete tmp files that are still in use.
relatime is a better option than noatime. it only updates atime if the file has been modified since the last atime update. this has obvious benefits for mail clients. it still doesn't fix the tmpreaper issue (a file may be read from /tmp for ages without being written to).
overall, the disadvantages are minor (non-existant except for a few special cases), and the performance benefit is significant.