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

tahoe-lafs trac at tahoe-lafs.org
Sun Dec 1 21:26:00 UTC 2013


#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:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * cc: warner (added)
 * keywords:  upload servers-of-happiness => upload servers-of-happiness
     brians-opinion-needed


Comment:

 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?

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


More information about the tahoe-lafs-trac-stream mailing list