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

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

View File

@ -246,7 +246,7 @@ stats_gatherer.furl = (FURL string, optional)
shares.needed = (int, optional) aka "k" shares.needed = (int, optional) aka "k"
shares.total = (int, optional) aka "N", N >= 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 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 is uploaded, erasure-coding is used to break the ciphertext into separate
@ -273,10 +273,13 @@ shares.happy = (int, optional) k <= happy <= N
uses. uses.
shares.happy allows you control over the distribution of your immutable file. 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 For a successful upload, shares are guaranteed to be initially placed on
'shares.happy' distinct servers, the correct functioning of at least k of at least 'shares.happy' distinct servers, the correct functioning of any
which is sufficient to guarantee the availability of the uploaded file. This k of which is sufficient to guarantee the availability of the uploaded file.
value should not be larger than the number of servers on your grid. 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 (Mutable files use a different share placement algorithm that does not
consider this parameter.) consider this parameter.)

View File

@ -3,12 +3,12 @@
When you upload a file to a Tahoe-LAFS grid, you expect that it will 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 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 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 helps to make sure that this actually happens.
upload health metric is essentially a test that looks at a file on a An upload health metric is a test that looks at a file on a Tahoe-LAFS
Tahoe-LAFS grid and says whether or not that file is healthy; that is, grid and says whether or not that file is healthy; that is, whether it
whether it is distributed on the grid in such a way as to ensure that it is distributed on the grid in such a way as to ensure that it will
will probably survive in good enough shape to be recoverable even if a probably survive in good enough shape to be recoverable, even if a few
few things go wrong between the time of the test and the time that it is 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 recovered. Our current upload health metric for immutable files is called
'servers-of-happiness'; its predecessor was called 'shares-of-happiness'. '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 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 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 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 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; health provides a stronger assurance of file availability over time;
with 3-of-10 encoding, and happy=7, a healthy file is still guaranteed with 3-of-10 encoding, and happy=7, a healthy file is still guaranteed
to be available even if 4 peers fail. 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 an expansion factor of 10x. Layouts that are declared healthy by the
bipartite graph matching approach have the property that they correspond bipartite graph matching approach have the property that they correspond
to uploads that are either already relatively efficient in their 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 that place all of the shares that they generate, enabling redistribution
of shares later without having to re-encode the file. Also, it is of shares later without having to re-encode the file. Also, it is
computationally reasonable to compute a maximum matching in a bipartite computationally reasonable to compute a maximum matching in a bipartite