From 184cae817234255eb6d5854d9e036c4687579867 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 2 Aug 2018 13:15:59 -0400 Subject: [PATCH] followup --- ..._42906e52528907a0960ab8b08c2eedd4._comment | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment diff --git a/doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment b/doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment new file mode 100644 index 0000000000..f19586dfcb --- /dev/null +++ b/doc/tips/local_caching_of_annexed_files/comment_4_42906e52528907a0960ab8b08c2eedd4._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2018-08-02T16:58:45Z" + content=""" +Parallel downloads will use the cache repository for everything if it has a +lower cost than other repositories. That's why the cost is set to 10 in the +example. If it has the same cost as another repository, parallel downloads +will spread the load between them. (This also means you can have multiple +caches with the same cost and distribute load amoung them..) + +You should never be pulling from the cache repo, so there should be nothing +to merge from it. That's what the remote.cache.annex-pull is there to prevent +git-annex sync doing, but you also have to avoid pulling from it yourself. + +Using tunables with the cache does seem to work. Since all remotes usually +have the same tunables as the local repo, there could potentially be +bugs (or optimisations?) where it applies the local tunables to the +remote, but in a little testing it seemed to work. +"""]]