[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