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

 Replying to [comment:13 zooko]:
 > Thanks, markberger!
 >
 > Replying to [comment:10 markberger]:
 > > Servers of happiness is not a boolean value. It is a measurement of
 how effectively shares are distributed. For each distinctive server with
 any nonzero number of shares, the servers of happiness value increases by
 1. In terms of how we model the problem, the servers of happiness value is
 len(E) where E is the set of edges used in the maximum matching bipartite
 graph of shares to servers.
 > >
 > > In terms of your example zooko, when you place a share on one server,
 you are constructing an edge between that share and that server in the
 bipartite graph. Therefore, the servers of happiness value is 1.
 >
 > Hm, isn't this true only if that share isn't already provided by another
 server? Or more precisely true only if ''some'' combination of the servers
 already holding shares wouldn't be able to provide the file in just as
 many cases ''without'' the addition of this new share?
 >
 >
 > Okay, so I ''think'' what this means is that sickness and amontero and
 me would be satisfied with Rule 3:
 >
 >    ''Rule 3: "Don't put a share on a server unless doing so would
 increase the Servers-of-Happiness-Level."''
 >
 > Does everyone agree that this is a good rule to enforce on an uploader
 or repairer? markberger? daira? sickness? amontero? brian?


 Looks like to me it would fulfill the needs of my scenario of "not wasting
 space in any storage node (waste=shares >k)" (#2123).

 Also, sickness' RAIC 1:2:2 example looks very appealing to me, with one
 question: would this modification allow you to add a 3rd. hot-spare node
 that would get its own share when repair is run? (ex. before
 decomissioning a soon-to-fail node)

 In other words: would this place shares above N's limit on new nodes not
 having none?

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