On Thu, Feb 10, 2022 at 09:49:14PM -0800, Kenneth Porter wrote:
--On Thursday, February 10, 2022 11:08 PM -0500 Jon LaBadie
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
--On Thursday, February 10, 2022 11:08 PM -0500 Jon LaBadie
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
On Thu, Feb 10, 2022 at 06:22:55PM -0800, Kenneth Porter wrote:
--On Thursday, February 10, 2022 8:49 PM -0500 Jon LaBadie
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
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,
Once upon a time, Kenneth Porter 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.
--On Thursday, February 10, 2022 8:15 PM -0600 Chris Adams
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
--On Thursday, February 10, 2022 8:49 PM -0500 Jon LaBadie
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
Once upon a time, Kenneth Porter 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 Thu, Feb 10, 2022 at 05:32:05PM -0800, Kenneth Porter wrote:
--On Thursday, February 10, 2022 8:03 PM -0500 Matthew Miller
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
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.
On Wed, Feb 9, 2022 at 5:10 PM Kenneth Porter
--On Thursday, February 10, 2022 8:03 PM -0500 Matthew Miller
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.
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?
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?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
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
14 matches
Mail list logo
