[tahoe-lafs-trac-stream] [tahoe-lafs] #1382: immutable peer selection refactoring and enhancements

[tahoe-lafs]

#1382: immutable peer selection refactoring and enhancements
------------------------------------+----------------------------------
     Reporter:  kevan               |      Owner:  markberger
         Type:  enhancement         |     Status:  new
     Priority:  major               |  Milestone:  eventually
    Component:  code-peerselection  |    Version:  1.8.2
   Resolution:                      |   Keywords:  design-review-needed
Launchpad Bug:                      |
------------------------------------+----------------------------------

Comment (by markberger):

 I'm currently figuring out the last few tests that fail with the new
 uploader. One of them is test_good_share_hosts in
 src/allmydata/test/test_checker.py. Here is a summary of the test:


 {{{
 N = 4
 k = 3
 happy = 1

 Initial sharemap:
     share -> [servers]
     0:[A] 1:[A] 2:[A] 3:[A,B,C,D,E]
     4 good shares, but 5 good hosts
 After deleting all instances of share #3 and repairing:
     0:[A,B], 1:[A,C], 2:[A,D], 3:[E]
     Still 4 good shares and 5 good hosts

 }}}

 However, with upload of happiness, repair produces

 {{{
 0:[A] 1:[A, B] 2:[C, A] 3:[E]
 }}}

 Is this behavior acceptable? The new algorithm views any additional share
 placements over N as redundant and does not attempt to place any more
 shares. However, this appears to be different from the old algorithm,
 which looks like it tried to place shares on as many servers as possible,
 regardless of N (at least from this test).

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