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

 Replying to [comment:26 zooko]:
 >
 > 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??)
 I agree with your definition of "Servers-of-Happiness-Level", but do not
 believe that rule 3 is the most intuitive and robust rule. If Tahoe is
 able to place a share in a way that reduces the number of nodes needed to
 recover a file, that should be done. That said, Tahoe should never
 intentionally store the same share twice (or we could end up at the
 degenerate case of all nodes have K shares).

 (Most of the following echos what [comment:27 gdt] said.)
 For example, I have a file encoded 2of5 and a grid with 2 nodes. Once each
 node has a share, the file is recoverable and the "Servers-of-Happiness-
 Level" cannot increase any further. I believe that each node should
 receive 2 shares distinct shares and the 5th should be discarded. This
 will allow the file to be recovered from either node but not waste any
 space on the grid. If a 3rd node comes online and a repair is preformed,
 the 5th share should be regenerated and placed on the 3rd node (both
 original nodes keep their same shares). If a 4th node comes online and a
 repair is preformed, one of the original nodes should transfer a share to
 the new node.

 Hopefully this is clear. I know how confusing matching intuition with
 formal definitions can be.

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