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

tahoe-lafs trac at allmydata.org
Sun Aug 16 19:45:35 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 zooko):

 Okay, I understand what you mean.  This hypothetical use case is in a
 sense the exact opposite of metacrob's.  He wants Tahoe-LAFS to give an
 error when there are only one or two storage servers, this other user
 would want Tahoe-LAFS to silently succeed in the same case.  If we
 implement {{{shares_of_happiness}}} as described so far in this ticket --
 with no special case and with no change to the upload peer selection
 algorithm -- then metacrob's use case will be satisfied by the default
 settings ({{{k=3, servers_of_happiness=7, m=10}}}), and the other use case
 would have to change their {{{k}}} and their {{{servers_of_happiness}}} to
 both be <= the number of servers that they actually have.  Is that right?

 We could implement metacrob's use case right now without -- the
 "servers_of_happiness = dont_care" feature -- and then wait until we have
 more information about how it works, for example a bug report from someone
 who expected upload to work with the default parameters when they had only
 one or two servers.

 What do you think of that?

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


More information about the tahoe-dev mailing list