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.
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?
On Wed, Feb 09, 2022 at 02:09:44PM -0800, Kenneth Porter wrote:
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.
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.
--On Thursday, February 10, 2022 8:03 PM -0500 Matthew Miller mattdm@mattdm.org wrote:
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.
On Thu, Feb 10, 2022 at 05:32:05PM -0800, Kenneth Porter wrote:
--On Thursday, February 10, 2022 8:03 PM -0500 Matthew Miller mattdm@mattdm.org wrote:
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.
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
--On Thursday, February 10, 2022 8:49 PM -0500 Jon LaBadie jcu@labadie.us wrote:
atime updates that occur when {m,c}time are updated add no additional burden.
Understood. If that's the only time it happened, I would be happy with that.
So you are concerned about a single "possible" inode update once a day?
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.
Once upon a time, Kenneth Porter shiva@sewingwitch.com said:
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.
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.
On Thu, Feb 10, 2022 at 06:22:55PM -0800, Kenneth Porter wrote:
--On Thursday, February 10, 2022 8:49 PM -0500 Jon LaBadie jcu@labadie.us wrote:
atime updates that occur when {m,c}time are updated add no additional burden.
Understood. If that's the only time it happened, I would be happy with that.
So you are concerned about a single "possible" inode update once a day?
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.
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.
--On Thursday, February 10, 2022 11:08 PM -0500 Jon LaBadie jcu@labadie.us wrote:
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.
On Thu, Feb 10, 2022 at 09:49:14PM -0800, Kenneth Porter wrote:
--On Thursday, February 10, 2022 11:08 PM -0500 Jon LaBadie jcu@labadie.us wrote:
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.
Once upon a time, Kenneth Porter shiva@sewingwitch.com said:
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.
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.
--On Thursday, February 10, 2022 8:15 PM -0600 Chris Adams linux@cmadams.net wrote:
Unless you never write to the disk, that will still be lost in the noise of writes.
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.
But if it still bothers you, use rsync --open-noatime.
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.
On 2/10/22 18:15, Chris Adams wrote:
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.
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).
-
Chris Adams -
Gordon Messmer -
Jon LaBadie -
Kenneth Porter -
Matthew Miller