Specifying a --bwlimit effects not only the network transfer speed but also the
speed at which files are checksumed. While this is technically not in violation
of the documentation, which says bwlimit effects the "I/O bandwidth", it does
make using rsync to sync up a large number of files over the network difficult
when you want to limit the network bandwidth.
For example. Say I have a directory of 10 files on the target server. I've
already downloaded 4 of them. I wish to use rsync to get the rest but I don't
want it to consume all my network bandwidth. So I run:
rsync --rvP --bwlimit=60k source.domain:/path/to/src dest
I would desire for the 4 local files to be checksumed as rapidly as possible,
disk I/O is not an issue, and then the 6 remaining files to be downloaded at the
limited rate of 60k as network bandwidth is an issue. The current
implementation applies the bwlimit to both the checksum and the network
bandwidth and the end result is the operation takes as long as had I just
downloaded all 10 files again defeating the point of rsync.
I can't say if the behavior and documentation of bwlimit should be changed or a
whole new "network transfer limit" flag be added. Either one would resolve my
This is with rsync 2.6.0 on OS X. I believe this is RsyncX's rsync. I do not
believe this is interferring and I did not see anything in the changes between
2.6.0 and 2.6.5 to suggest this has been fixed. My apologies if it has.
$ rsync --version
rsync version 2.6.0 protocol version 27
Copyright (C) 1996-2004 by Andrew Tridgell and others
HFS+ filesystem support for OSX (C)2004 Kevin A. Boyd
Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
IPv6, 32-bit system inums, 64-bit internal inums
My mistake, there is no bug. I was rsyncing to the wrong directory so the local
files weren't there.