From a92a23fe343862f2dba1c7cfddc01f0f595551d0 Mon Sep 17 00:00:00 2001 From: david-sarah Date: Thu, 17 Jun 2010 22:07:10 -0700 Subject: [PATCH] configuration.txt and servers-of-happiness.txt: 1 <= happy <= N, not k <= happy <= N. Also minor wording changes. --- docs/configuration.txt | 13 ++++++++----- docs/specifications/servers-of-happiness.txt | 18 +++++++++--------- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/docs/configuration.txt b/docs/configuration.txt index 398ba1d9..1ab7ebf6 100644 --- a/docs/configuration.txt +++ b/docs/configuration.txt @@ -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.) diff --git a/docs/specifications/servers-of-happiness.txt b/docs/specifications/servers-of-happiness.txt index 493094bf..67c6d713 100644 --- a/docs/specifications/servers-of-happiness.txt +++ b/docs/specifications/servers-of-happiness.txt @@ -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 -- 2.45.2