#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 davidsarah):
Replying to [comment:21 swillden]:
> Perhaps it would be better to measure happiness by "number of servers
that can fail without losing the file"? I think that makes the
implications of setting the parameter much easier for users to understand,
and it's not complicated for Tahoe to compute: Just generate the peer
list, assign share counts to the peers, sort by share count (ascending),
and sum up the list until {{{total >= k}}}. The number of remaining,
unsummed, servers is the maximum that can be lost without losing the file.
This sounds like the right thing to me.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:24>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
_______________________________________________
tahoe-dev mailing list
[email protected]
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
