Rsync help needed...

Matt McCutchen hashproduct at verizon.net
Thu Feb 23 22:58:09 GMT 2006


On Thu, 2006-02-23 at 14:32 -0500, Linus Hicks wrote:
> At a minimum, when an Oracle database is opened and closed, the timestamps on 
> all datafiles will be updated because the header blocks will get updated with a 
> new SCN. So the timestamps on all datafiles will always look different the next 
> time you rsync. The --checksum will just cause extra I/O.

Linus, by "timestamps", do you mean the files' filesystem-level mtimes
or timestamps embedded in their data?

> Consider using --inplace and --no-whole-file. If you don't use --inplace, rsync 
> will write a temporary file, then copy it. This requires additional disk space 
> as well as the time and potentially extra I/O.

Not exactly: if --inplace is not used, rsync will write a temporary file
and atomically move it over the original.  --inplace uses less disk
space but does not provide atomicity and, according to the man page,
reduces the efficiency of the incremental transfer algorithm.

For reference, here is how much _disk_ I/O the receiving rsync performs
when transferring a source file to an identical destination file.  To
find this out, I ran rsync-acl 2.6.7pre2 on a 1 MB test file of all
zeros and searched strace output for reads and writes with long runs of
zeros; I used -z so the network I/O wouldn't have long runs of zeros.

Temporary file, incremental transfer: generator reads destination file,
receiver reads destination file, receiver writes a temporary file.

In place, incremental transfer: generator reads destination file,
receiver reads destination file, nothing is written (destination file is
found to be fine as-is).

Temporary file, whole file transfer: receiver writes a temporary file.

In place, whole file transfer: receiver writes destination file.

lsk, since you are using incremental transfer, --inplace will
significantly reduce the amount that the receiver writes; I would
recommend it if atomicity is not necessary.

--inplace also has the advantage of not disturbing the
non-permission-bit entries of a file's access ACL if they differ from
those of the default ACL of the file's containing directory when --perms
is disabled.  Although this situation is extremely rare, it might be
nice if rsync-acl loaded an existing destination file's access ACL along
with its permissions in the dest_mode function.
-- 
Matt McCutchen
hashproduct at verizon.net
http://hashproduct.metaesthetics.net/



More information about the rsync mailing list