blob: 2caeef11d3e6ed48d65dc973431a7858ec621fdf (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
[[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, stored in the git-annex branch.
> This is now done, however, there are 3 known
> problems:
>
> * tahoe start run unncessarily <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2149>
> * web.port can conflict <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2147>
> * Nothing renews leases, which is a problem on grids that expire.
> <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2212>
> --[[Joey]]
|
