[tahoe-lafs-trac-stream] [tahoe-lafs] #1212: Upload (sometimes?) ignores shares.happy in tahoe.cfg

[tahoe-lafs]

#1212: Upload (sometimes?) ignores shares.happy in tahoe.cfg
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  kmarkley86
  eurekafag              |     Status:  closed
         Type:  defect   |  Milestone:  1.8.1
     Priority:           |    Version:  1.8.0
  critical               |   Keywords:  regression repair servers-of-
    Component:  code-    |  happiness
  network                |
   Resolution:  fixed    |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by davidsarah):

 * status:  new => closed
 * resolution:   => fixed
 * milestone:  1.10.0 => 1.8.1


Old description:

> I've tried to repair a file and got:
>

> {{{
> <class 'allmydata.interfaces.UploadUnhappinessError'>: shares could be
> placed on only 5 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 7
> such servers. (placed all 10 shares, want to place shares on at least
> 7 servers such that any 3 of them have enough shares to recover the
> file, sent 7 queries to 5 peers, 7 queries placed some shares, 0
> placed none (of which 0 placed none due to the server being full and 0
> placed none due to an error))
> }}}
>
> Everything worked fine on 1.7.1 and shares.happy = 3 (didn't changed it
> after upgrade). So I did a little investigation and found the problem.
> It's immutable/repairer.py, line 60:
>

> {{{
> happy = upload.BaseUploadable.default_encoding_param_happy
> }}}
>

> Why do we use default happy here? It definitely should be read from
> the config. I didin't dig further but replaced it with ugly hack:
>

> {{{
> happy = 3 #upload.BaseUploadable.default_encoding_param_happy
> }}}
>

> ...and the problem has gone! Repairing works with just 6 servers
> online.

New description:

 I've tried to repair a file and got:


 {{{
 <class 'allmydata.interfaces.UploadUnhappinessError'>: shares could be
 placed on only 5 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 7
 such servers. (placed all 10 shares, want to place shares on at least
 7 servers such that any 3 of them have enough shares to recover the
 file, sent 7 queries to 5 peers, 7 queries placed some shares, 0
 placed none (of which 0 placed none due to the server being full and 0
 placed none due to an error))
 }}}

 Everything worked fine on 1.7.1 and shares.happy = 3 (didn't changed it
 after upgrade). So I did a little investigation and found the problem.
 It's immutable/repairer.py, line 60:


 {{{
 happy = upload.BaseUploadable.default_encoding_param_happy
 }}}


 Why do we use default happy here? It definitely should be read from
 the config. I didin't dig further but replaced it with ugly hack:


 {{{
 happy = 3 #upload.BaseUploadable.default_encoding_param_happy
 }}}


 ...and the problem has gone! Repairing works with just 6 servers
 online.

--

Comment:

 Moved to #1830. The original problem was fixed in 1.8.1 I think. See #1130
 and #1382 for other improvements to share placement and servers-of-
 happiness.

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