Added a comment

1 files changed, 14 insertions, 0 deletions

diff --git a/doc/todo/faster_rsync_remotes/comment_3_2f6a9d23cb8351fbf0f60ed93752e76e._comment b/doc/todo/faster_rsync_remotes/comment_3_2f6a9d23cb8351fbf0f60ed93752e76e._comment
new file mode 100644
index 000000000..1911048be
--- /dev/null
+++ b/doc/todo/faster_rsync_remotes/comment_3_2f6a9d23cb8351fbf0f60ed93752e76e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.145"
+ subject="comment 3"
+ date="2013-08-01T16:58:49Z"
+ content="""
+git-annex needs to build a specific directory structure on the rsync remote though. It seems it would need to build the whole tree locally, containing only the files it wants to send.
+
+When using encryption, it would need to encrypt all the files it's going to send and store them locally until it's built the tree. That could use a lot of disk space.
+
+Also, there's the problem of checking which files are already present in the remote, to avoid re-encrypting and re-sending them. Currently this is done by running rsync with the url of the file, and checking its exit code. rsync does not seem to have an interface that would allow checking multiple files in one call. So any optimisation of the number of rsync calls would only eliminate 1/2 of the current number.
+
+When using ssh:// urls, the rsync special remote already uses ssh connection caching, which I'd think would eliminate most of the overhead. (If you have a version of git-annex older than 4.20130417, you should upgrade to get this feature.) It should not take very long to start up a new rsync over a cached ssh connection. rsync:// is probably noticably slower.
+"""]]