On Mon, 26 Jun 2000, Dave Dykstra wrote:
>
> First of all: when rsyncing over NFS, the rsync algorithm actually
> makes for worse performance because it not only reads entire "from"
> and "to" files to calculate checksums but also sends the checksums
> and the entire "to" file. Use the -W option to disable the rsync
> algorithm.
Is this a special case for NFS filesystems? I don't have
--checksum specified, although now I realize I may have misinterpreted
the meaning of that switch. --checksum has nothing to do with the
internal rsync block checksum, but rather a more robust way to
determine if a file has changed (instead of relying solely on
timestamp and file length)?
/usr/local/buffer/bin/rsync \
--archive \
--delete \
--exclude ".snapshot/" \
--hard-links \
--one-file-system \
--stats \
--log-format "[%p] %t: %o %f (%b/%l)" \
$*
I'll try with --whole-file tonight and see how it goes. The
current dataset is about 240GB and 10.8 million files, with multiple
parallel rsyncs chewing away at it, so any performance improvement is
welcome. :)
> The author of rsync Andrew Tridgell said this when he released 2.4.3:
>
> Finally a plea. When reporting a freeze _please_ include the following
> or we can't help:
>
> - what is the state of the send/receive queues shown with netstat on
> the two ends.
> - what system call is each of the 3 processes stuck in. Use truss on
> solaris or strace on Linux.
Will do.
--
Brian Tao (BT300, [EMAIL PROTECTED])
"Though this be madness, yet there is method in't"
