I often use rsync as basically an scp with resume functionality, but
there are a couple annoyances that've often come to mind while doing
this.
The first is that if I've already transferred a significant amount of a
large file, the ETA is rather on the low side because rsync only takes
into account the starting time, current time, and the current offset in
the file when computing the transfer rate. One way to get a more
accurate result would be to use the actual amount of data transferred
during the current session, rather than just the current offset. Another
approach might be to take a rolling average of the transfer rate during
the last, say, 10 seconds. These could be alternatives to the current
method, specifiable as options on the command line or whatever.
The second issue I have is not such a big deal, but could be
improved. Again, if I'm transferring a large file and I break off the
transfer at some point, resuming it with rsync will cause it to compute
a bunch of hashes for the already-transferred data. Obviously, it has to
do this to give a correct result in the general case, but supposing that
I'm reasonably sure that the already-transferred portion is good, it
would be nice to have an option to just resume directly without any
hashing (I'm reasonably sure there isn't one already, but I could be
wrong).
Would anyone else find these options useful? I'd be willing to work on
either or both, but I'm wondering if they would be
useful/acceptable/desirable. Thoughts?
-Jeremy
