Any Downside To Mount -o Noatime?

Home » CentOS » Any Downside To Mount -o Noatime?
CentOS 13 Comments

I’d like to reduce the wear-and-tear on my SSDs and eliminate the unnecessary metadata writes on my backup media that only slow down the backup process. So I want to add noatime to all my mounts. Is there any downside to this?

At one time I remember atime being useful for tmpwatch, which removes files in /tmp that haven’t been accessed in a week or two. But I can live without that feature.

13 thoughts on - Any Downside To Mount -o Noatime?

  • Also, is there a way to make noatime the default for all mounts? Or will I need to add it to everything in /etc/fstab and
    /etc/systemd/system/*.mount?

  • relatime has been the default for a long time — that only updates atime once per some reasonable timeperiod. The wear and tear from that is negligible and you can still get a basic idea of when files where accessed.

  • –According to the man page for mount, relatime updates atime whenever mtime or ctime are updated, or if neither has been updated in the last 24 hours. Which is still prohibitive if you’re doing an incremental (rsync) backup and checking file contents on the “full” backup weekly or monthly.

    The only apps I’ve found that need atime are tmpwatch and biff, neither of which I use.

  • You may get just as much SSD “savings” by putting /var/log and /tmp into a RAM disk. I do this with all of my Raspberry Pi’s, since SD cards burn through pretty quickly, and I have several that haven’t had their SD cards replaced in a couple years.

  • atime updates that occur when {m,c}time are updated add no additional burden.

    So you are concerned about a single “possible” inode update once a day?

    jl

  • Once upon a time, Kenneth Porter said:

    Unless you never write to the disk, that will still be lost in the noise of writes. But if it still bothers you, use rsync –open-noatime.

  • –Understood. If that’s the only time it happened, I would be happy with that.

    I’m using BackupPC to do rsync-based backups of all my systems. The
    “incremental” backups look only at size and timestamp changes. The less-frequent “full” backups checksum all my files. That means an extra write for every file that gets checked.

    I’d love to have a version of relatime that only did the first kind of update, when ctime or mtime changed but not when 24 hours had passed.

  • –Consider a weekly backup of /usr with checksumming of the contents. A
    partition that only changes with updates, so in principle it could be mounted read-only except when I yum update. Although of course since it’s not SUPPOSED to change, an incremental backup should only be done after that yum update. The main value I can see with atime on /usr is to identify trash that I’m not using and that should be uninstalled.

    That would be handy if I actually needed atime! I hadn’t noticed that one. Although I’m reading that the containing directory’s atime does get updated.

  • Once upon a time, Kenneth Porter said:

    Well, not really. atime writes would get batched just like any other write, and filesystems have inode metadata grouped together, so it’d be more like one flush of a few inode metadata blocks for a whole lot of atime updates.

    Unless you had zero other writes (in which case, why back up), this will still be lost in the noise of total writes. Any old SSD will handle that just fine for many years to come.

  • I’d have suggested that, except that as far as I can tell, it doesn’t apply to directories.  Even with that option, the directory crawl results in lots of writes to both the source and destination volume
    (which stinks if the backup volume is slow, as they often are).

  • From an earlier post:

    “According to the man page for mount, relatime updates atime
    whenever mtime or ctime are updated, or if neither has been
    updated in the last 24 hours.”

    Are you reading that as “atime gets updated every 24 hrs”? If so you are missing “if needed”. I.e. if the file’s data blocks have been read.

    Checking time-stamps and sizes are not operations that cause atime updates. Those are inode operations, not data reads.

  • –That I got. I was concerned with the case where rsync does a checksum to verify that the file’s contents didn’t change without changing the timestamp.

  • Which you indicated are “less frequent” for full backups. How often are full backups done?

    And no, it would not be a write for each file. It would be an update to the in memory version of the inode. At some point it will be written back to “disk”. But only as a block of many inodes for many files. Some of those files may not even have had any timestamp changes. Others might require that the block of inodes be written because there was an mtime, ctime, size, permission change in any one of the inodes in the block. But it would be one write for all the inodes in that block.