[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:  enhancement      |     Status:  new
     Priority:  normal           |  Milestone:  undecided
    Component:  code-            |    Version:  1.10.0
  peerselection                  |   Keywords:  upload servers-of-happiness
   Resolution:                   |
Launchpad Bug:                   |
---------------------------------+-----------------------------------------

Comment (by 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.

 However, we do use a boolean value to indicate whether a file is healthy.
 We should measure this value by h_actual >= h_min where h_actual is the
 happiness value of the share distribution and h_min is the minimum
 happiness level specified by the user. However, this hasn't been
 implemented yet (see ticket #614).

 h_max is defined as min(len(shares), len(servers)) where shares and
 servers are sets. This is because we will always be limited by the
 smallest set in a maximum matching bipartite graph.

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