[tahoe-lafs-trac-stream] [tahoe-lafs] #2107: don't place shares on servers that already have shares

[tahoe-lafs]

#2107: don't place shares on servers that already have shares
-------------------------+-------------------------------------------------
     Reporter:  zooko    |      Owner:
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  normal   |    Version:  1.10.0
    Component:  code-    |   Keywords:  upload servers-of-happiness brians-
  peerselection          |  opinion-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by zooko):

 Replying to [comment:25 PRabahy]:
 > My vote (if I get one) is to leave this as it currently is.

 Wait, I'm sorry but I don't know what that means. The whole topic is
 dizzyingly confusing to me. It's ''amazing'' to me that after, what 14
 years of working with wide-area decentralized erasure-coding, I can't even
 formulate a rigorous statement of ''what I want''.

 PRabahy: what do you think of "Rule 3"?

     ''Rule 3: "Don't put a share on a server unless doing so would
 increase the Servers-of-Happiness-Level."''

 Where "Servers-of-Happiness-Level" is defined as:

     ''Servers-of-Happiness-Level: the size of the largest set of servers
 such that '''any''' K-sized subset of it can recover the file.''

 (I think. Did I get that definition right??)

 gdt: what do you think of Rule 3?

 My guess is that none of the following people even ''understand'' what
 Servers of Happiness or Rule 3 mean: PRabahy, sickness, amontero, gdt,
 zooko, warner. That leaves daira, markberger, and Kevin Carstensen as the
 only people on the planet who understand what Servers of Happiness even
 means.

 This is distressing to me, because of the notion that a thing isn't good
 enough just by providing good behavior, but in addition to that it also
 has to be ''understandable'' and ''predictable'' behavior to users. I'm
 currently thinking that no decentralized erasure-coding system can do
 that. Perhaps The only solution is to strip erasure-coding out of a future
 version of LAFS and make K always = 1 (i.e. straight replication). ;-)

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2107#comment:26>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage