[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better
tahoe-lafs
trac at allmydata.org
Sun Aug 16 19:45:35 PDT 2009
#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 zooko):
Okay, I understand what you mean. This hypothetical use case is in a
sense the exact opposite of metacrob's. He wants Tahoe-LAFS to give an
error when there are only one or two storage servers, this other user
would want Tahoe-LAFS to silently succeed in the same case. If we
implement {{{shares_of_happiness}}} as described so far in this ticket --
with no special case and with no change to the upload peer selection
algorithm -- then metacrob's use case will be satisfied by the default
settings ({{{k=3, servers_of_happiness=7, m=10}}}), and the other use case
would have to change their {{{k}}} and their {{{servers_of_happiness}}} to
both be <= the number of servers that they actually have. Is that right?
We could implement metacrob's use case right now without -- the
"servers_of_happiness = dont_care" feature -- and then wait until we have
more information about how it works, for example a bug report from someone
who expected upload to work with the default parameters when they had only
one or two servers.
What do you think of that?
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:17>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list