Mount options – atime vs relatime

Have you ever asked yourself, what the difference between the mount option atime and relatime is?
In this short blog post, we tell you the main difference of these options and for what you should use relatime.

With the mount option relatime, the access time (atime) will not be written to the disc during every access. The access time (atime) will only change, if one of these two points occurs:

  • the modified time (mtime) or change time status (ctime) of a file is newer than the last access time (atime).
  • the access time (atime) is older than a defined interval (1 day by default on a RHEL system).

So the relatime mount option is a nice mix between the options atime and noatime and useful for applications, which need the access time (atime) of a file. With the relatime option, there will not be as much traffic on the disk, if a file is often accessed. For example on a webserver is the mount option relatime a good solution, because here are many read actions, but the atime will only updated once a day (with the 24 hours interval setting).

If you use a solid-state disk (SSD) and have no application which needs the access time, you should use the mount option noatime.


  • Dominique Barton Reply

    I think we need to be more specific for relatime, because it’s not essentially true that relatime is only updating the time once a day.

    relatime was introduced in the 2.6.20 kernel and it basically only updates the atime when the previous atime was older than the mtime or ctime. Later this behaviour was changed a bit so relatime will also update the atime if the previous atime was older than 24h.

    So if you don’t modify your file, then the atime will only updated once in 24h. But every time you modify your file (and therefor update the mtime timestamp), you’ll also update the atime timestamp because to previous one is older than the new mtime timestamp.

  • Dominique Barton Reply

    Btw. in the 4.0 kernel there’s a new feature called lazyupdate (mount option lazytime) which basically stores the timestamp changes in memory and flushes them later to disk, together with non-timestamp related I/O’s on the same file.

  • Mike Uchima Reply

    Another situation where you really should consider noatime is when you are using drive-managed SMR (shingled) drives, such as the Seagate xxxxDM004 series. Recursively sweeping through a file system with lots of small files, say to compute checksums for all the files or back the files up to another location will generate a lot of random writes due to the access time updates; and sustained random writes are problematic for drive-managed SMR. I have seen situations where this can cause I/O latencies to get so bad (multiple minutes!) that the system resets the drive, resulting in failed I/Os. On a RAID setup, this can cause drives to get kicked out of the array.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.