ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-05-02 17:12:59 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

configuration.txt and servers-of-happiness.txt: 1 <= happy <= N, not k <= happy <= N. Also minor wording changes.

Browse Source
This commit is contained in:
david-sarah 2010-06-17 22:07:10 -07:00
parent 390fc78a9a
commit a92a23fe34
2 changed files with 17 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/configuration.txt
View File

@ -246,7 +246,7 @@ stats_gatherer.furl = (FURL string, optional)
shares.needed = (int, optional) aka "k"
shares.total = (int, optional) aka "N", N >= k
shares.happy = (int, optional) k <= happy <= N
shares.happy = (int, optional) 1 <= happy <= N
These three values set the default encoding parameters. Each time a new file
is uploaded, erasure-coding is used to break the ciphertext into separate
@ -273,10 +273,13 @@ shares.happy = (int, optional) k <= happy <= N
uses.
shares.happy allows you control over the distribution of your immutable file.
An upload is only considered successful if shares are placed on at least
'shares.happy' distinct servers, the correct functioning of at least k of
which is sufficient to guarantee the availability of the uploaded file. This
value should not be larger than the number of servers on your grid.
For a successful upload, shares are guaranteed to be initially placed on
at least 'shares.happy' distinct servers, the correct functioning of any
k of which is sufficient to guarantee the availability of the uploaded file.
This value should not be larger than the number of servers on your grid.
A value of shares.happy <= k is allowed, but does not provide any redundancy
if some servers fail or lose shares.
(Mutable files use a different share placement algorithm that does not
consider this parameter.)

18
docs/specifications/servers-of-happiness.txt
View File

@ -3,12 +3,12 @@
When you upload a file to a Tahoe-LAFS grid, you expect that it will
stay there for a while, and that it will do so even if a few of the
peers on the grid stop working, or if something else goes wrong. An
upload health metric helps to make sure that this actually happens. An
upload health metric is essentially a test that looks at a file on a
Tahoe-LAFS grid and says whether or not that file is healthy; that is,
whether it is distributed on the grid in such a way as to ensure that it
will probably survive in good enough shape to be recoverable even if a
few things go wrong between the time of the test and the time that it is
upload health metric helps to make sure that this actually happens.
An upload health metric is a test that looks at a file on a Tahoe-LAFS
grid and says whether or not that file is healthy; that is, whether it
is distributed on the grid in such a way as to ensure that it will
probably survive in good enough shape to be recoverable, even if a few
things go wrong between the time of the test and the time that it is
recovered. Our current upload health metric for immutable files is called
'servers-of-happiness'; its predecessor was called 'shares-of-happiness'.
@ -27,9 +27,9 @@ servers-of-happiness addresses this by extending the share-focused
upload health metric to also consider the location of the shares on
grid. servers-of-happiness looks at the mapping of peers to the shares
that they hold, and compares the cardinality of the largest happy subset
of those with a user-configurable threshold (A happy subset of peers has
of those to a user-configurable threshold. A happy subset of peers has
the property that any k (where k is as in k-of-n encoding) peers within
the subset can reconstruct the source file). This definition of file
the subset can reconstruct the source file. This definition of file
health provides a stronger assurance of file availability over time;
with 3-of-10 encoding, and happy=7, a healthy file is still guaranteed
to be available even if 4 peers fail.
@ -65,7 +65,7 @@ is inefficient; for k = 3, and if there are n peers, it corresponds to
an expansion factor of 10x. Layouts that are declared healthy by the
bipartite graph matching approach have the property that they correspond
to uploads that are either already relatively efficient in their
utilization of space, or can be made to be so by deleting shares, and
utilization of space, or can be made to be so by deleting shares; and
that place all of the shares that they generate, enabling redistribution
of shares later without having to re-encode the file. Also, it is
computationally reasonable to compute a maximum matching in a bipartite