Future RSYNC enhancement/improvement suggestions

David Bolen db3l at fitlinxx.com
Mon Apr 22 17:28:01 EST 2002


Martin Pool [mbp at sourcefrog.net] writes:

> No, I think you could avoid it, and also avoid the up-front traversal
> of the tree, and possibly even do this while retaining some degree of
> wire compatibility.  It will be a fair bit of work.

Yeah, I was sort of thinking bang for the buck - munging with the file
list handling reaches into far more code and would likely be far more
effort to change within the current rsync source than the checksum
transmission.  I think the checksum would just be moving the
equivalent of send_sums right into generate_sums and only touching the
single generate.c module, with no noticeable difference on the wire or
to other modules.

I did go back and take a current look at our current transfers for the
one task this for which this could make the most difference.  For the
~110GB of data we synchronize each month (over V.34 dialup lines :-)),
the "wasted" time with our current network/filesystem looks to be in
aggregate only about 7.5 hours of phone time, which in turn is only
about 1.6% of the ~480 hours used each month.  So it's hard to worry
extensively about that 1.6%.

-- David

/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/




More information about the rsync mailing list