[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:  warner
     Type:  defect                     |          Status:  new   
 Priority:  critical                   |       Milestone:  1.6.0 
Component:  code-peerselection         |         Version:  1.4.1 
 Keywords:  reliability review-needed  |   Launchpad_bug:        
---------------------------------------+------------------------------------

Comment(by kevan):

 Replying to [comment:139 zooko]:
 > I don't understand this comment. It appears that the code is blindly
 clobbering entries in {{{self.preexisting_shares}}}. Does that mean that
 the code is ''not'' making sure that we don't unintentionally report a
 lower happiness value than actually exists?  I think it would make sense
 to turn {{{self.preexisting_shares}}} into a map from sharenum to a set of
 serverids instead of from sharenum to serverid.
 >
 > If the code above ''is'' reporting a lower happiness value than it ought
 then we should be able to write a unit test that fails in which the file
 is actually happy but the upload reports it as unhappy.

 The point of {{{should_add_server}}} is to make sure that that assignment
 only happens if it would make {{{self.preexisting_shares}}} happier than
 it already is -- that's what the if-statement is checking. Maybe I don't
 understand what you mean when you say blindly clobbering shares?

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