== The limitations of Unix _atime_ 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.)