I am trying to optimize my new fs layout, and I wondered, where is it safe to use noatime? I understand that e.g. mutt uses the access/creation/modify time, and whatever else may be using that, in whichever dir.

Following a ton of guides, I have partitioned my dirs according to different use-cases, but I don't really know, where is it safe to put noatime?

dirs / flags:

/               defaults
    /dev ...)

/boot           defaults
/boot/EFI       defaults

/usr            defaults,ro,nodev
                    NOTE: dpkg needs rw
/usr/share      defaults,ro,nodev,nosuid

/var            defaults,nodev
                    NOTE: /var/lib/dpkg/info -> exec
/var/tmp        defaults,nodev,nosuid,noexec
/var/log        defaults,nodev,nosuid,noexec

/opt            defaults,nodev

/tmp            defaults,nodev,nosuid,noexec
                    NOTE: some installer may need exec

/home           defaults,nodev,nosuid

1 Answer 1


AFAIK it's the very rare program indeed that relies on atime, and using noatime is safe virtually everywhere.

The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:

mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.

Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.

And using noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard relatime, saving every write on a flash/SSD is good):

Linux: Replacing atime With relatime

Submitted by Jeremy on August 7, 2007 - 11:26am

In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "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." Ingo Molnar stressed the significance of fixing this performance issue, "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, combined." He submitted some patches to improve relatime, and noted about atime:

"It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"

There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:

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.

answered Jul 29 '09 at 11:09

  • For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY
    – Zoltan K.
    Commented Mar 6, 2019 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .