blob: 4e0bf2fb1642b8c6553359c315f115791c96b84d (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
[[forum/tips:_special__95__remotes__47__hook_with_tahoe-lafs]] is a good
start, but Zooko points out that using Tahoe's directory translation layer
incurs O(N^2) overhead as the number of objects grows. Also, making
hash subdirectories in Tahoe is expensive. Instead it would be good to use
it as a key/value store directly. The catch is that doing so involves
sending the content to Tahoe, and getting back a key identifier.
This would be fairly easy to do as a [[backend|backends]], which can assign its
own key names (although typically done before data is stored in it),
but a tahoe-lafs special remote would be more flexible.
To support a special remote, a mapping is needed from git-annex keys to
Tahoe keys.
The best place to store this mapping is perhaps as a new field in the
location log:
date present repo-uuid newfields
This way, each remote can store its own key-specfic data in the same place
as other key-specific data, with minimal overhead.
Unfortunatly, the current location log parser throws out lines that it
cannot parse, so making this change would involve something of a flag day
upgrade. Also unfortunatly, the location log and other .git-annex/ data
does not have its own version that can be checked to force an upgrade
across all clones. It might be best to deal with this at the same time
the ideas in [[branching]] are done. --[[Joey]]
|
