[tahoe-lafs-trac-stream] [tahoe-lafs] #1212: Repairing fails if less than 7 servers available

[tahoe-lafs]

#1212: Repairing fails if less than 7 servers available
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  sickness
  eurekafag              |     Status:  reopened
         Type:  defect   |  Milestone:  1.8.1
     Priority:  major    |    Version:  1.8.0
    Component:  code-    |   Keywords:  reviewed regression repair news-
  network                |  needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by kmarkley86):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening this ticket.  I'm affected by the same fundamental problem, but
 by a different path.  The fix identified earlier was to
 immutable/repairer.py, but I'm getting an error from immutable/upload.py.

 Scenario:
 I'm using 2-of-4 encoding with shares.happy=4 on tahoe 1.8.1.  From the
 CLI I do a tahoe check --repair on a file with shares {0, 2, 3} already
 existing on the grid but share 1 not existing, and I get an
 UploadUnhappinessError complaining that "we were asked to place shares on
 at least 7" servers.  There are only 4 servers on my grid -- hence my
 choice of shares.happy=4.

 I observed that in immutable/upload.py, BaseUploadable has a statement
 "default_encoding_param_happy = 7".  I tried the experiment of changing
 this value to 4 (the shares.happy value in my tahoe.cfg) and then the
 repair succeeds without error.

 So there must be a path through this code where the
 default_encoding_param_happy value is actually used instead of being
 overridden by the value in tahoe.cfg.  (I think it smells a little that
 this object has defaults at all, instead of requiring the parameters to be
 provided.)

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