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

 Replying to [comment:18 zooko]:
 > Replying to [comment:17 amontero]:
 > >
 > > 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?
 >
 > This would not. If you want that, then you should probably set N higher
 in the first place. E.g. you could have two servers, K=1, H=2, and set
 N=3. Then whenever the uploader or repairer runs, it puts one share on
 each of the two servers and considers itself to have succeeded.

 Actually it will also put the 3rd share on one of the two servers.

 > If you attach a third server, then it would attempt to upload a 3rd
 share to that 3rd server.

 In that case repair would upload another copy of the 3rd share to the 3rd
 server, yes. When #1816 is fixed, only 3 shares would have their leases
 renewed (the redundant copy of the 3rd share on one of the first two
 servers would not).

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