[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:           
--------------------------------+-------------------------------------------

Comment(by kevan):

 I was working on the documentation updates for this ticket earlier today,
 and:

 >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).

 started bugging me.

 As I understand it, the purpose of this ticket is to fix the issue that
 metacrob mentioned on the mailing list -- that Tahoe should not consider
 an upload successful if it cannot place shares on at least servers of
 happiness servers. The naive and, to me, obivious way to do this is to
 keep track of how many distinct servers we use when uploading a file, and
 then failing if, when there are no more outstanding shares, we haven't
 used servers of happiness servers.

 However, this technique doesn't seem to achieve the goal of the wording
 above.

 Let's suppose that I have a file {{{f}}}, default encoding parameters
 {{{k=3, M=10, happy=2}}}, and that there are enough servers in my grid so
 that I can find a distinct server to accept each share. If I'm using tahoe
 patched with my naive solution above, the upload will succeed, but since
 every server only has one of 10 shares, and {{{k=3}}}, the correct
 functioning of 2 servers is not enough to guarantee the availability of my
 file.

 An obvious enough solution to this is to ignore values of happy that are
 less than {{{k}}}. But there are use cases for values of happy that are
 less than {{{k}}} -- e.g., if I just want an offsite backup somewhere and
 don't care very much about reliability beyond that. Maybe we should just
 change the description of happy to remove any guarantees about
 reliability, leaving that instead for some of the tickets referenced in
 the first comment.

 Hopefully this doesn't come off as me being pedantic about wording -- I'm
 just trying to make sure that I'm on the same page as you on what needs to
 be done with this ticket.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:6>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid