[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 zooko):

 > I'm not sure how this k interacts with the number-of-shares k. Are you
 assuming implicitly that there is only one share per server?

 Treat that as an "implementation detail" that Tahoe-LAFS can optimize as
 it likes, as long as the guarantee that it offers to the user still holds:
 that there are {{{h}}} servers, the survival of any {{{k}}} of which will
 guarantee the survival of the file.  (Where there will be {{{m}}} total
 servers if possible, but at least {{{h}}} servers, or else the upload
 fails.)

 That seems to be what users like metacrob think that we are already
 offering, and it is also the property that I would like from my backups.
 It is "the erasure-coding property" as applied to servers, not to shares.
 (Under the hood, of course, Tahoe-LAFS has to produce shares and then
 decide how to upload them in order to achieve this property and also to
 optimize other things like up- and down- transfer performance.)

 (Also, I think that it can be implemented as a small patch to the current
 upload algorithm.)

 Shawn: what do you think?

 Kevan: you're now my test to see whether I'm making sense about this
 topic.  Is the above coherent?  :-)

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