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

[tahoe-lafs]

#1212: Repairing fails if less than 7 servers available
------------------------------+---------------------------------------------
     Reporter:  eurekafag     |       Owner:          
         Type:  defect        |      Status:  closed  
     Priority:  major         |   Milestone:  soon    
    Component:  code-network  |     Version:  1.8.0   
   Resolution:  fixed         |    Keywords:  reviewed
Launchpad Bug:                |  
------------------------------+---------------------------------------------
Changes (by zooko):

  * keywords:  review-needed => reviewed
  * status:  new => closed
  * resolution:  => fixed
  * milestone:  undecided => soon


Comment:

 Reviewed and applied in
 [20100927200102-b8d28-9111a341188a4264e5070f91b52364a2addcb3dc], thanks!
 By the way, I think we should do more work here. This patch corrects the
 regression from v1.7.1 to v1.8.0 (introduced in
 [20100804072639-66853-20d40fc1f412f916adfe1aaa1b2035dbd590107f]), in that
 v1.7.1 would repair with a servers-of-happiness ({{{H}}}) of {{{0}}} and
 v1.8.0 would repair with an {{{H}}} of {{{7}}}. While I agree that this
 was a regression and that we should put it back to {{{0}}}, I actually
 think that the old behavior of {{{0}}} was wrong and that we should have
 been using "currently configured {{{H}}}" instead!

 That is: if you have configured your servers-of-happiness {{{H}}} to be 3,
 like eurekafag did, and the number of servers currently reachable on your
 grid is 2, and you do a repair, then I think the repair should stop with
 an explicit error message instead of proceeding and then giving you a
 report at the end that mentions (if you know how to read it) that it
 actually only put the shares onto 2 servers.

 (In other words, I think I was wrong when I suggested letting repairer use
 {{{H==0}}} in comment:48:ticket:778. Or at least, what we did then was to
 keep the behavior of repairer from v1.6 when we made v1.7, but what I'm
 suggesting to do now is improve that behavior for the next release.)

 Kevan, David-Sarah, Brian, eurekafag: do you agree? If so, let's open a
 new ticket saying to make the {{{H}}} used by repair be the same as the
 {{{H}}} that would be used by an upload. (Also in the new code we should
 make the {{{H}}} value be a parameter passed to the repairer instead of
 letting the repairer query the node-wide configuration. This is in keeping
 with [wiki:CodingStandards#configuration CodingStandards regarding
 configuration] and will facilitate some possible future work where people
 can pass explicit {{{K}}}, {{{M}}}, and {{{H}}} for a given upload or
 repair, e.g. as options to the {{{tahoe put}}} command line or optional
 fields in the WUI.

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