On Mon, Jun 26, 2000 at 06:50:25PM -0400, Brian Tao wrote:
> 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? 

You just need to be aware that the rsync protocol between client and server
is optimized for minimal bandwidth usage, and that is traded off for
increased local disk access.  When you do a local copy to NFS-mounted file
systems, your client and server are both on the same machine (with gobs of
bandwidth between them!) and your "local" disk access is over a network.


> 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)?

Exactly.  If you can trust the timestamps, you don't need --checksum.



> /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.  :)

If a lot of files change, then --whole-file should be an improvement.  If
very few files change, you probably won't notice much difference.

- Dave Dykstra

Reply via email to