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

[tahoe-lafs]

#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