[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better
tahoe-lafs
trac at allmydata.org
Mon Aug 17 13:39:37 PDT 2009
#778: "shares of happiness" is the wrong measure; "servers of happiness" is
better
--------------------------------+-------------------------------------------
Reporter: zooko | Owner:
Type: defect | Status: new
Priority: critical | Milestone: undecided
Component: code-peerselection | Version: 1.4.1
Keywords: reliability | Launchpad_bug:
--------------------------------+-------------------------------------------
Comment(by swillden):
Replying to [comment:22 zooko]:
> So I think what I really want is to make {{{servers_of_happiness}}} mean
"The number of servers in set X" and {{{k}}} mean "Any subset of X of size
k is sufficient to recover the file".
>
> I guess that means {{{servers_of_happiness}}} is "The minimum number of
servers (such that any {{{k}}} of those servers is sufficient) to consider
this upload a success.". Is that right?
I'm not sure how this {{{k}}} interacts with the number-of-shares {{{k}}}.
Are you assuming implicitly that there is only one share per server? I
think there are good reasons to have more than one share per server (to
maximize download performance while still assuring reliability), in which
case the number-of-shares {{{k}}} must be distinct from, and larger than,
the number-of-servers {{{k}}}. So it appears that this formulation of the
approach requires '''two''' parameters: minimum-recoverable-server-set-
size ({{{k_server}}}) and servers-of-happiness ({{{h}}}). These are in
addition to the FEC parameters, {{{k_share}}} and {{{m}}}}.
The more I think about this, the more confusing servers-of-happiness
becomes as a measure or selector of reliability. But then, I'm easily
confused :-)
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:23>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list