Recently, I've come to believe that Unix's file (okay, inode) access time is increasingly useless. The problem isn't that Unix is slipshod about maintaining atime; the problem is that there are now an increasing number of things that read files as a routine matter, and so file atime is increasingly nothing more than the last time one of them ran.

The most obvious example is any backup program that works through the filesystem, which most of them do (especially the commercial ones). Modern GUI desktops often open files that they come anywhere near (to show you pretty pictures and other previews of them); after that there's the growing popularity of desktop search systems, which read all of your files to index them.

(Note that resetting the access time with utime(2) is a cure worse than the disease, since doing that updates ctime and in turn makes any competent backup system think that all of the files have changed and need to be backed up.)

Despite all of this atime is still somewhat useful, so I haven't disabled it on most of my systems since the overhead is low (and it requires explicit steps to disable).

Sidebar: why disable atime?

The reason to disable atime updates is disk IO bandwidth; you don't have to write all of those updated inodes to disk, which in turn can save you a boatload of seeks since inodes are often scattered more or less randomly around the disk. Since seeks are the really time-consuming thing on modern disks, avoiding a bunch of them can be a serious win, especially in environments where writes hit multiple disks like RAID-1 or RAID-5 setups.

(One of the original groups that really loved the ability to turn off atime updates was Usenet server admins, back in the days of 'one article per file' news spool directories where even skimming through a newsgroup might require reading a bit of hundreds of files. News was often IO constrained and the atime of Usenet articles was basically pointless, so.)