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

tahoe-lafs trac at allmydata.org
Tue Aug 18 15:00:21 UTC 2009

#778: "shares of happiness" is the wrong measure; "servers of happiness" is
 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

 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

More information about the tahoe-dev mailing list