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