Relatime Recap

Linus just made relatime the default atime behavior for file systems (thanks to mjg59’s hard work), although I suspect it won’t remain the default or in this particular form for long. People are still asking the same questions about atime as they did 2 or 3 years ago, so I thought I’d do a quick recap.

  • Q: Why do I care about atime anyway?
  • A: atime (“access time”) is a POSIX defined file property that records the last time a file’s data or metadata was read. This turns every read of a file into a small write. Reading a lot of files (as in, say, a recursive grep) will cause a sudden storm of random write I/Os even if all the actual data to read is in cache, which uses up disk I/O bandwidth, spins up the disk if it was idle, and generally wastes power, wears out the disk, and speeds the heat death of the universe. Thus, atime is considered to be one of the great misfeatures of UNIX.
  • Q: So let’s just not update atime at all. I hear there’s this “noatime” mount option that’s been around for years.
  • A: “noatime” is great and some distros turned it on by default for a while. I use it and I tell anyone who asks me to turn on noatime. Then one of my friends complained that mutt no longer knew when it had new mail when she turned on atime. (In some configurations, mutt depends on atime being updated on mbox format mailboxes.) noatime breaks a small but important set of applications, and so most distros couldn’t turn it on by default without generating a flood of complaints. (NB: “nodiratime” only turns off atime on directories but not files (noatime does both); this was a different compromise and broke another set of applications for somewhat less benefit.)
  • Q: Okay, how about we just update atime in memory and never write it out disk?
  • A: When the cached inode gets kicked out of memory and then reread from disk, the atime as viewed from the application point of view will go backwards in time. This is a little too non-POSIX for most people. It’s worth noting, though, that XFS had a bug which resulted in exactly this behavior for months (years?) and no one ever noticed.
  • Q: Fine, let’s update atime in memory and then write it out to disk only when the inode gets evicted from memory.
  • A: One of the XFS guys, Dave Chinner, told me that they had a serious problem with this kind of strategy in other use cases. If you have a lot of memory in relation to the number of disk iops available, you could easily build up enough inode updates to keep the disk busy for 10s of minutes straight. See, the writes are random and scattered around the disk, so the disk becomes IO bound on a per-operation level (on the order of a hundred IOs per second). Everything is fine until you get enough memory pressure to start kicking inodes out of cache You want to be writing these inode updates out to disk on an ongoing basis rather than letting them pile up indefinitely, which gets us back to regular atime behavior.
  • Q: Damn. So what do we do now?
  • A: The idea I came up with a couple of years ago is to only update the atime if the previous atime was older than the file’s mtime or ctime – that is, the file’s data or metadata has been changed since the last time the atime was updated. Now you know if the file has been accessed relative to the last time it was changed. This solved my friend’s mutt new mail notification problem and made it possible for distros to turn on “relatime” (relative atime) by default.
  • Q: Any problems with that?
  • A: Other than the fact that “relatime” (relative atime) looks like “realtime” misspelled, certain applications (e.g., tmpwatcher) want to know if a file has been accessed at all in the last <timeperiod>. This made it impossible to turn relatime on by default in some distros, which was the whole point of the feature. So a variety of people (Ingo Molnar, Matthew Garrett, and Andrew Morton that I recall) rewrote the patch over the years to update the atime if it was older than some period of time (configurable variously via /proc, kernel config value, mount option, tapping Morse code into the speaker, etc.). Two years of bikeshedding ensued. Some distros included the patches to configure the time period but they weren’t in mainline yet.
  • Q: So how come it’s the default now?
  • A: The Linux community is currently convulsed by file system performance and correctness issues. relatime came up in a discussion about ext3 IO latency and this time it piqued Linus’ interest enough to merge in non-configurable form. But Linus says he’ll consider adding a configuration knob:
    On Thu, 26 Mar 2009, Andrew Morton wrote:
    > I (and others) pointed out that it would be better to implement this as
    > a mount option. That suggestion was met with varying sillinesses and
    > that is where things stand.
    I'd suggest first just doing the 24 hour thing, and then, IF user space
    actually ever gets its act together, and people care, and they _ask_ for a
    mount option, that's when it's worth doing.
  • Q: I think what Linus merged is a horrible idea! What can I do?
  • A: On an individual level, you can specify the “strictatime” mount option. If you have wider concerns, download the latest kernel git snapshot, run it, see what breaks, and post to LKML (preferably with patches – check the archives, there is probably already one that does what you want). I’m pretty sure this patch will be modified before the next release (or possibly reverted), so right now is a golden opportunity to affect it.

22 thoughts on “Relatime Recap”

  1. use the apps packages

    How about turning it off by default. Then modify the packages that need it to turn it back on if they get installed. Print out big ugly message about how this ruins your performance and maybe the app authors will take the hint.

  2. Relatime is a cool compromise, great idea!

    The lkml thread prompted me to add noatime to my workstation disk. The description of relatime in the mount(8) man page was just cryptic enough that I didn’t want to expend the brain cells yesterday to figure out if it did what I wanted it to do. I’m doing a ton of kernel builds – git clone; make all; rm -rf – even the single atime update might be more than I really want to take.

    But all my problems will hopefully go away soon; I have a shiny new X25-E winging its way to me as I type :-)

  3. So.. do *you* think it’s a good idea to merge this? I can’t tell if you think it’s not likely to stick because it’s not a good default behavior or because it’s not politically viable?

  4. If you are the kind of person who reads this blog and worries about things like their mount options, you should go ahead and use noatime. If stuff breaks, you’ll know the reason and either suck it up or go back to normal atime.

    If you are nearly everyone else in the entire world, you’re not going to even be aware of the question. Hell, even I don’t remember to turn on noatime. Which is why it would be nice if the kernel could have a default that does the right thing invisibly.

  5. I think that by merging it as a non-configurable default, Linus has broken the bikeshedding logjam. Which is good. I hope it sticks, but I’m not picky about the form.

  6. You can to it per-dir too with an attr…

    As I recently learned from the inimitable Mr. Tso:
    “Alternatively, you can use chattr +A to set the noatime flag on all files and directories where you don’t want noatime semantics, and then clear the flag for the Unix mbox files where you care about the atime updates. Since the noatime flag is inherited by default, you can get this behaviour by setting running chattr +A /mntpt right after the filesystem is first created and mounted; all files and directories created in that file system will have the noatime file inherited.”

    Of course… I find attributes annoying because they are “hidden”. So I just do noatime and assume that I always have mail^uspam so there will be something there whenever I type mutt.


  7. Re: You can to it per-dir too with an attr…

    No, no, no, no, no. People won’t even turn off atime on their entire file systems, there’s no way they will turn it back on for one directory.

    In file systems, anything that is per-directory or per-file like this fails.

  8. Re: Is O_NOATIME unrestricted now?

            /* O_NOATIME can only be set by the owner or superuser */
            if ((arg & O_NOATIME) && !(filp->f_flags & O_NOATIME))
                    if (!is_owner_or_cap(inode))
                            return -EPERM;
  9. Yep, I read that as realtime. Whups.

    I’m building a new testing box this weekend, I’ll give a fresh git kernel a shot and see what I think. After a year of RHEL and old Debian at work, I’m sure I’ll be surprised :)

  10. Thanks for covering the pros and cons

    I have been in enough bike shedding arguments over this topic to be happy to have something that I can now point to.

    The mail problem is a definite one that I have run into in various imap products where turning off atime had it that no one got any email.. but not turning it off causes the load average go to 100 when 3 or 4 people with thousands of emails in their folders log in (the mail system uses mh style storage of email.) Sadly the file systems are on NFS so I am pretty well stuck with it :).

    Thank you.

  11. Re: You can to it per-dir too with an attr…

    I don’t know: in the mutt case, mutt developpers know that the application need the access time of the mails so they could ensure that mutt add a ‘atime’ attribute to the directory checked by mutt.

    So mutt would work even in a FS mounted in ‘noatime’ mode.

  12. Let the kernel detect which files need atime?

    Is it really just a small number of programs that really read the atime value, or is it just a small number of apps which break after getting wrong atimes?

    My proposal:
    Why not introducing a file flag which says “please update atime” whenever the atime of some file is read, and removing this flag after the atime was updated once.
    Anticipated effects:
    1. If the machine runs no software which reads the atime, then eventually no more atime updates will be made.
    2. If a program runs which accesses the atime of certain files (like /tmp/* or mbox), then those files will repeatedly get their flag back, keeping the atime up to date.
    3. If a program runs which accesses the atime of almost all file on in the fs, then… well, many file will get the atime flag and it has to be considered as the user’s wish to do all those hardly necessary write IOs.

    Regards, Ulf

  13. Re: Thanks for covering the pros and cons

    Why not use Maildir instead it ? It was meant for handling NFS wel if I remember correctly.


  14. Multiple filesystems

    I’m one of those strange people who doesn’t use one-big-root-filesystem for this reason among others. I like to mount a lot of my filesystem noatime, and others I want full atime support.

    For the record, I mount /home and /var with atime enabled, and the root filesystem with noatime. I have a few subdirectories of /var on some machines that have their own mount points without atime (like /var/www if doing web hosting).

    Using multiple mount points is so very simple in *nix systems already, and LVM makes it a no-brainer as later expansion of misjudged ‘partition’ sizes is quite simple.

    All that to say I think forced broken-atime in the kernel is a bad idea.

  15. What about semantics?

    I like the “update atime in memory and write it to disk later” approach most.
    Cache is everything!

    Sure, if you do it wrong your system can hang for seconds to minutes (yes, nobody wants that – but if you do things wrong all sorts of stupid stuff may happen, anyway).
    But this is the _only_ way to keep the original atime semantics _without_ sacrificing performance (too much). All other approaches change semantics (which is evil; ext3/4 had enough of that, recently), but caching is “only” an implementation issue.

    Personally, I just use noatime for months, without any bad side effects. But that’s only because i (obviously) don’t use programs that need atimes, which isn’t a real solution.

  16. Re: You can to it per-dir too with an attr…


    While I agree with your statement completely, I just wanted to highlight a somewhat different use case where this chattr works great.

    I have a couple of USB sticks I carry around everywhere and mount on all sorts of machines, and I want to ensure they would *never* have atime switched on (due to the number of files on them and the way I use them).

    In other words, chattr lets me keep the “noatime” requirement *with* the actual filesystem. If I close one eye and squint sideways at it I can sort of pretend it’s actually one of the -o flags in tune2fs :-)


    Sitaram Chamarty (

  17. From the application programmer’s perspective, what is needed is a way to differenciate between atime reads and file reads. For example, suppose an application wants to read a file’s atime, it should access that data in a read-only way so as not to alter the atime.

    So why should we be limited to atime, ctime and mtime? How about adding a new field, ratime (‘readonly atime’)?


Comments are closed.