[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 kevan):

 I like the idea of extending the peer selection algorithm -- it'd be cool
 to be able to support choices of {{{servers_of_happiness}}} that are less
 than {{{k}}}, but I'm not sure how to do that. An algorithm for that
 probably wouldn't be too difficult, but maybe beyond the scope of this
 ticket? I'm fine with failing with an error, too.

 As you say, what we're effectively saying with the backup scenario is that
 we don't care how many servers need to stay up to guarantee availability
 of data -- i.e.: we don't have a {{{servers_of_happiness}}}. Saying
 {{{servers_of_happiness=1}}} is certainly a way of supporting that, but it
 seems confusing to adopt that as the standard -- we're special casing a
 configuration value to mean something when set to a particular value that
 it doesn't mean with other values (not to mention the fact that there
 might be users who would want the correct functioning of any one of the
 servers that they've uploaded shares to for a file to guarantee
 availability of that file). I think it'd be better if we supported the
 backup scenario by not performing the {{{servers_of_happiness}}} behavior
 unless the user has explicitly set a {{{servers_of_happiness}}} value in
 the config file (we could support this in code by using 0 as a default or
 something). This seems more consistent with what the user is saying with
 that value -- if they don't set it, they don't care, and if they do, then
 we can interpret it in a way that doesn't involve too many special cases.

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