links, typos
[Imported from Trac: page ServerSelection, version 3]
parent
feae9b1fb1
commit
5b0217e094
|
@ -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.
|
||||||
|
|
Loading…
Reference in a new issue