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

 Replying to [comment:31 zooko]:
 >
 > ''Servers-of-Happiness-Level: how many "server↔share" pairs are there,
 '''not''' counting any server more than once and '''not''' counting any
 share more than once.''

 …following-up to my own post…

 Oh, to be more precise, we have to specify that the Servers-of-Happiness-
 Level is the size of the ''largest'' such set of "server↔share" pairs.
 There is only one such set of "server↔share" pairs in the "ideal" case
 (e.g. number of servers > {{{N}}}, no server disconnects before an upload
 and then reconnects after an upload, etc.), but there could be different
 ways to choose "server↔share" pairs in non-ideal cases, such as:

     "server↔share" pairs:

  * server 0 ↔ share 1
  * server 1 ↔ share 1
  * server 1 ↔ share 2
  * server 2 ↔ share 2

 To determine what the Servers-of-Happiness-Level of this situation is, you
 have to pick a subset of the pairs so that the resulting subset doesn't
 have any server appearing more than once or any share appearing more than
 once. Therefore the ''Servers-of-Happiness-Level'' of this situation is
 {{{2}}}.

 So, this ticket (#2107) is about an uploader or repairer choosing ''not''
 to upload a share to any server, if uploading that share would not
 increase the Servers-of-Happiness-Level. For example, in the case shown
 above, if the uploader is considering uploading share 0, it could do that
 an increase the Servers-of-Happiness-Level from {{{2}}} to {{{3}}}:

     "server↔share" pairs:

  * server 0 ↔ share 0
  * server 0 ↔ share 1
  * server 1 ↔ share 1
  * server 1 ↔ share 2
  * server 2 ↔ share 2

 But once it has done that, if it is then considering uploading share 3, it
 ''cannot'' increase the Servers-of-Happiness-Level by uploading share 3,
 so if #2107 is accepted, it will not upload share 3 at all.

 If I understand correctly, sickness, amontero, and recent-zooko are in
 favor of #2017 — do ''not'' upload a share if doing so does not increase
 the Servers-of-Happiness-Level — and gdt and previous-zooko are in favor
 of the opposite — go ahead and upload an extra share even if it doesn't
 increase Servers-of-Happiness-Level. I ''think'' PRabahy's comment:29 is
 suggesting a different metric (which doesn't yet have a name), and in
 order to achieve that metric you have to upload shares even when uploading
 them doesn't increase the Servers-of-Happiness-Level.

 Daira's comment:28 is pretty persuasive to me: let's not do ticket #2107
 until after Tahoe-LAFS v1.11 is released, on the basis of not changing
 multiple things at a time unnecessarily.

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