[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 20:39:37 UTC 2009

#778: "shares of happiness" is the wrong measure; "servers of happiness" is
 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