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

[tahoe-lafs]

#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:20 terrell]:
 > {{{k=1, happy=1, m=X}}} -- not recommended, no redundancy
 > {{{k=2, happy=2, m=X}}} -- friendnet, backup guaranteed (minimal
 protection)
 > {{{k=3, happy=3, m=X}}} -- friendnet, backup guaranteed (better
 protection)

 Without specifying m, you can't really be sure that the "protection level"
 statements are true.  For example, with {{{k=2, happy=2, m=3}}}, only one
 of the two guaranteed servers has enough shares to reconstruct the file,
 so if that server fails, you've lost the file, which I would call "single
 point of failure", not "minimal protection".

 If {{{happy == k}}}, you need {{{m > k + 1}}} or you have a single point
 of failure.

 Perhaps it would be better to measure happiness by "number of servers that
 can fail without losing the file"?  I think that makes the implications of
 setting the parameter much easier for users to understand, and it's not
 complicated for Tahoe to compute:  Just generate the peer list, assign
 share counts to the peers, sort by share count (ascending), and sum up the
 list until {{{total >= k}}}.  The number of remaining, unsummed, servers
 is the maximum that can be lost without losing the file.

 Obviously in the case that spawned this ticket, metacarob's max-losable
 would be zero, a very bad situation for reliability.  Setting max-losable
 to one would provide a guarantee of minimal redundancy, setting it to two
 or three would provide good reliability.

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