tahoe-lafs/trac-2024-07-25
2
0
Issues 1.1k Wiki Activity

links, typos 

[Imported from Trac: page ServerSelection, version 3]
davidsarah 2009-10-19 18:12:32 +00:00
parent feae9b1fb1
commit 5b0217e094
1 changed files with 8 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
ServerSelection.md

@ -20,11 +20,11 @@ would be pretty easy to make the uploader use different classes according to
a `tahoe.cfg` option. a `tahoe.cfg` option.
However, there are some additional properties that need to be satified by the However, there are some additional properties that need to be satified by the
sever-selection algorithm for it to work at all. The basic Tahoe model is server-selection algorithm for it to work at all. The basic Tahoe model is
that the filecap is both necessary and sufficient (given some sort of grid that the filecap is both necessary and sufficient (given some sort of grid
membership) to recover the file. This means that the eventual membership) to recover the file. This means that the eventual
**downloader** needs to be able to find the same servers, or at least have **downloader** needs to be able to find the same servers, or at least have
a sufficiently-high probability of finding "enough" servers within a a sufficiently high probability of finding "enough" servers within a
reasonable amount of time, using only information which is found in the reasonable amount of time, using only information which is found in the
filecap. filecap.
@ -37,12 +37,12 @@ track down and update all of the old shares: the chance of accidental
rollback increases when it cannot reliably/cheaply find them all. rollback increases when it cannot reliably/cheaply find them all.
Another potential goal is for the download process to be tolerant of new Another potential goal is for the download process to be tolerant of new
servers, removed servers, and shares which have been moved (possibly as the servers, removed servers, and shares that have been moved (possibly as the
result of repair or "rebalancing"). Some use cases will care about this, result of repair or "rebalancing"). Some use cases will care about this,
while others may never change the set of active servers and won't care. while others may never change the set of active servers and won't care.
It's worth pointing out the properties we were trying to get when we came up It's worth pointing out the properties we were trying to get when we came up
with the current "tahoe2" algorithm: with the current "TahoeTwo" algorithm:
* for mostly static grids, download uses minimal do-you-have-share queries * for mostly static grids, download uses minimal do-you-have-share queries
* adding one server should only increase download search time by 1/numservers * adding one server should only increase download search time by 1/numservers
@ -52,7 +52,7 @@ with the current "tahoe2" algorithm:
* traffic load-balancing: all non-full servers get new shares at the same * traffic load-balancing: all non-full servers get new shares at the same
bytes-per-second, even if serverids are not uniformly distributed bytes-per-second, even if serverids are not uniformly distributed
We picked the pseudo-random permuted serverlist to get these properties. I'd We picked the pseudo-random permuted serverlist [on the [StorageIndex](StorageIndex)]dependent
love to be able to get stronger diversity among hosts, racks, or data to get these properties. I'd love to be able to get stronger diversity among
centers, but I don't yet know how to get that **and** get the properties hosts, racks, or data centers, but I don't yet know how to get that **and**
listed above, while keeping the filecaps small. get the properties listed above, while keeping the filecaps small.