[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:                |  
------------------------------+---------------------------------------------

Comment (by kevan):

 If we do that, we lose the property that the repairer will always try to
 place whichever shares are missing onto *some* storage servers, even if
 the end result isn't optimally distributed.

 If I have a cron job that does a deep repair of my rootcap, and the
 rootcap or some other important dircap or filecap only has {{{k}}} or
 {{{k+1}}} shares available, and it is stored on a grid with a lot of
 churn, I probably care more about the fact that there are more than a few
 shares of that cap around than I do about where they are, and I certainly
 wouldn't want the repairer to not even bother generating new ones because
 it couldn't satisfy my distribution criteria; IOW, I'm better off with
 more shares that are poorly distributed than I am with no repair action
 (I'm oversimplifying, and it depends on the specific situation, but having
 more shares will make things better in some situations and generally won't
 make things worse, AFAICT without doing the math).

 On the other hand, I think that the repairer should definitely tell the
 user whether the file is distributed correctly or not, and an exception
 message certainly does that. I can also make my node's repair go for broke
 with share regeneration by changing the value of happiness in
 {{{tahoe.cfg}}} to be 0. This is a chore, but it means that people who
 really want the repairer to try to place new shares regardless of where
 can still get that behavior.

 Maybe the best approach is to fix #614 with this in mind. The repairer
 could regenerate and try to place all of the missing shares, as it does
 now, but also tell the caller (in the post repair results) whether the
 repair was ultimately successful or not based on how the shares are
 distributed, using the client's configured happiness value for that check.

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