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

tahoe-lafs trac at allmydata.org
Thu Jan 21 06:14:01 PST 2010


#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 zooko):

 Replying to [comment:146 kevan]:
 > I'm not sure what I think about making preexisting_shares a map to a set
 of peerids. It would remove the need for {{{should_add_server}}}, but
 would also make the end calculations more complicated. I'll think about
 that when I've worked through the rest of your comments.

 Okay, think about it!

 > (of course, if I'm wrong in my last comment, maybe it makes sense to do
 that regardless of complexity)

 Yeah, there are two notions of "complexity". One is computational --
 basically "the size of the code for the shortest implementation of this".
 The other is cognitive -- basically "the difficulty for the Tahoe-LAFS
 hackers to learn this and then to hold it correctly in their heads".

 It ''might'' be the case that making both data structures be maps from
 shareid to set of serverid would make the algorithm "simpler" in the
 latter way -- easier to comprehend. I'm not sure.

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


More information about the tahoe-dev mailing list