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