[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 2 10:27: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:
--------------------------------+-------------------------------------------
metcarob posted a nice clear bug report to the list:
http://allmydata.org/pipermail/tahoe-dev/2009-August/002494.html
{{{
On Sunday,2009-08-02, at 10:57 , <gc20090728 at metcarob.com>
<gc20090728 at metcarob.com> wrote:
I have set up a grid with one intorducer node and one storage node. I took
my browser to the 3456 port as the instructions say and I was surprised
when I was able to sucessfully upload a file.
As I understand it tahoe will split the file into 10 parts and save each
part on a diffrent server. This would mean that if a server crashes you
still can get the file. I was expecting to have an error message saying
that the grid wasn't big enough to reliably save the file. Instead all the
parts of the file have been saved on the same server. Why isn't the error
message there?
}}}
Zooko writing: I've mentioned this a few times before, but I don't think
there is a ticket about this exact issue. Basically, the concept of
"shares of happiness" (the number of shares, the successful upload of
which means that your file is safely uploaded) is almost never what people
want. A more useful concept is "servers of happiness" (the number of
servers, the survival and correct function of which will guarantee that
your file is available).
"Servers of happiness" isn't going to be right for everyone, though.
Eventually some people are going to need #573 (Allow client to control
which storage servers receive shares), where they get to specify complex
policies like "This upload was successful if at least three different
geographic sites have {{{K+1}}} shares each.".
I'm marking this as "priority: critical" instead of the standard priority
(which is called "major"), because it could be a reliability problem for
users such as metcarob who aren't already familiar enough with the details
of Tahoe-LAFS architecture to avoid the problem. I'm also marking it with
the keyword "reliability".
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list