Hello, 

since we are using rsync for backing up millions of files in a virtual 
environment, and most of the virtual machines run on SSD cached storage, i`d be 
curious how that negatively impacts lifetime of the SSD`s when we do rsync run 
every night for backup

my question:
does rsync normal file comparison run to determine if anything has changed 
change atime of any files ?

for me it seems, stat/lstat calls of rsync do NOT modify atime, but i`m not 
sure under which conditions atime is changed. 

grepping the source for O_NOATIME in rsync3.txt i found :

  - Propagate atimes and do not modify them.  This is very ugly on
    Unix.  It might be better to try to add O_NOATIME to kernels, and
    call that.

furhermore, apparently there _IS_ O_NOATIME in linux kernels for a while:

http://man7.org/linux/man-pages/man2/open.2.html

O_NOATIME (since Linux 2.6.8)
              Do not update the file last access time (st_atime in the
              inode) when the file is read(2).

              This flag can be employed only if one of the following
              conditions is true:

              *  The effective UID of the process matches the owner UID of
                 the file.

              *  The calling process has the CAP_FOWNER capability in its
                 user namespace and the owner UID of the file has a mapping
                 in the namespace.

              This flag is intended for use by indexing or backup programs,
              where its use can significantly reduce the amount of disk
              activity.  This flag may not be effective on all filesystems.
              One example is NFS, where the server maintains the access
              time.


so, maybe someone likes to comment on NOATIME !? 

maybe it could be useful to make rsync honour O_NOATIME ?

regards
roland

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Reply via email to