[tahoe-lafs-trac-stream] [tahoe-lafs] #1791: UploadUnhappinessError with available storage nodes > shares.happy

[tahoe-lafs]

#1791: UploadUnhappinessError with available storage nodes > shares.happy
---------------------------+-----------------------------------------------
     Reporter:  gyver      |      Owner:  gyver
         Type:  defect     |     Status:  new
     Priority:  major      |  Milestone:  1.11.0
    Component:  code-      |    Version:  1.9.2
  peerselection            |   Keywords:  servers-of-happiness upload error
   Resolution:             |
Launchpad Bug:             |
---------------------------+-----------------------------------------------

Comment (by daira):

 From #2016 which has now been marked as a duplicate:

 [//trac/tahoe-lafs/ticket/2016#comment:2 daira] wrote:
 > Here's the most important part of the log:
 {{{
 local#675138 20:33:50.290: <Tahoe2ServerSelector for upload jbljj>(jbljj):
 response to allocate_buckets() from server i76mi6: alreadygot=(0,),
 allocated=()
 local#675139 20:33:50.457: <Tahoe2ServerSelector for upload jbljj>(jbljj):
 response to allocate_buckets() from server lxmst5: alreadygot=(2,),
 allocated=(1,)
 local#675140 20:33:50.667: <Tahoe2ServerSelector for upload jbljj>(jbljj):
 response to allocate_buckets() from server sf7ehc: alreadygot=(3,),
 allocated=()
 local#675141 20:33:50.822: <Tahoe2ServerSelector for upload jbljj>(jbljj):
 response to allocate_buckets() from server ddvfcd: alreadygot=(4,),
 allocated=()
 local#675142 20:33:50.839: <Tahoe2ServerSelector for upload jbljj>(jbljj):
 server selection unsuccessful for <Tahoe2ServerSelector for upload jbljj>:
  shares could be placed on only 4 server(s) such that any 3 of them have
 enough shares to recover the file, but we were asked to place shares on at
 least 5 such servers.
  (placed all 5 shares, want to place shares on at least 5 servers such
 that any 3 of them have enough shares to recover the file, sent 6 queries
 to 6 servers, 4 queries placed some shares, 2 placed none (of which 2
 placed none due to the server being full and 0 placed none due to an
 error)),
  merged=sh0: i76mi6en, sh1: lxmst5bx, sh2: lxmst5bx, sh3: sf7ehcpn, sh4:
 ddvfcdns
 }}}

 [//trac/tahoe-lafs/ticket/2016#comment:3 daira] wrote:
 > Here's my interpretation: with h = N = 5, as soon as the
 Tahoe2ServerSelector decides to put two shares on the same server (here
 sh1 and sh2 on lxmst5bx), the upload is doomed. The shares all have to be
 on different servers whenever h = N, but the termination condition is just
 that all shares have been placed, not that they have been placed in a way
 that meets the happiness condition.

 > If that's the problem, then #1382 should fix it. This would also explain
 why VG2 was unreliable with h close to N.

 [//trac/tahoe-lafs/ticket/2016#comment:4 zooko] replied:
 > Daira: excellent work diagnosing this!! Ed: thanks so much for the bug
 report. Daira: it looks like you are right, and I think this does explain
 those bugs that the volunteergrid2 people reported and that I never
 understood. Thank you!

 [//trac/tahoe-lafs/ticket/2016#comment:6 kapiteined] wrote:
 > And to check if that is the case, i changed to 3-7-10 encoding, and now
 the upload succeeds! {{{Success: file copied}}}

 > Does this call for a change in code, or for a big warning sticker:
 "don't choose h and n to close together" ?

 [//trac/tahoe-lafs/ticket/2016#comment:7 daira] wrote:
 > We intend to fix it for v1.11 (Mark Berger's branch for #1382 already
 basically works), but there would be no harm in pointing out this problem
 on tahoe-dev in the meantime.

 [//trac/tahoe-lafs/ticket/2016#comment:9 daira] wrote:
 >> Same bug as #1791?
 >
 > Yes, that bug also had h = N and two shares that were placed on the same
 server, so almost identical. I'll copy the conclusions here to that
 ticket.

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