[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better

tahoe-lafs trac at allmydata.org
Wed Aug 19 17:11:58 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:31 zooko]:
 > I think I like your and Shawn's proposed algorithm for how to  choose
 {{{k_e}}} and {{{m_e}}} and to map shares onto servers.  However, it
 should be a separate ticket from this one.  The reason is that there is (I
 think) a very easy way to implement this ticket without implementing that
 improved algorithm.  That is: let {{{k_e = k}}}, {{{m_e = m}}} (the same
 as it is now), then run the current algorithm for mapping-shares-to-
 servers, then check if the result satisfies the new criteria for success.

 That seems like it works fine.  The only major advantage of the "new"
 algorithm is increasing parallelism for downloads, which is a separate
 issue, and should be a separate ticket (I'll open one).  In fact, I think
 there's a much simpler way to increase parallelism.

 To be clear, the "new criteria for success" are, I believe:

 1.  Any {{{k}}}-server subset of the {{{n}}} successful servers has
 sufficient shares to construct the file.  If {{{k = k_e, n >= k}}}, this
 is trivially guaranteed to be satisfied.  If {{{n < k}}}, then we don't
 have the FEC survivability guarantee, but survivability degrades fairly

 2.  {{{n >= h}}}.

 Where {{{n}}} is the number of servers that receive at least one share, of

Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:33>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid

More information about the tahoe-dev mailing list