[tahoe-dev] [tahoe-lafs] #661: Dynamic share migration to maintain file health

tahoe-lafs trac at allmydata.org
Wed Mar 24 20:27:24 PDT 2010


#661: Dynamic share migration to maintain file health
---------------------------+------------------------------------------------
     Reporter:  mmore      |        Type:  enhancement                     
       Status:  new        |    Priority:  major                           
    Milestone:  undecided  |   Component:  code-encoding                   
      Version:  1.3.0      |    Keywords:  repair preservation availability
Launchpad_bug:             |  
---------------------------+------------------------------------------------
Changes (by davidsarah):

  * keywords:  => repair preservation availability


Comment:

 The following clump of tickets are closely related:
  * #450 Checker/repair agent
  * #483 Repairer service
  * #543 Rebalancing manager
  * #643 Automatically schedule repair service
  * #661 Dynamic share migration to maintain file health
  * #864 Automated migration of shares between storage servers

 Actually there are probably too many overlapping tickets here.

 Part of the redundancy is due to distinguishing repair from rebalancing.
 But when #614 and #778 are fixed, a healthy file will by definition be
 balanced across servers, so there's no need to make that distinction.
 Perhaps there will also be a "super-healthy" status that means shares are
 balanced across the ''maximum'' number of servers, i.e. N. (When we
 support geographic dispersal / rack-awareness, the definitions of
 "healthy" and "super-healthy" will presumably change again so that they
 also imply that shares have the desired distribution.)

 There are basically four options for how repair/rebalancing could be
 triggered:

  * a webapi operation performed by a gateway, and triggered by CLI
 commands. We already have this. Scheduling this operation automatically is
 #643.
  * triggered by write operations on a particular file. This is #232 and
 #699.
  * moving a server's shares elsewhere when it is about to be
 decommissioned or is running out of space. This is #864.
  * a more autonomous repair/rebalancing service that would run
 continuously.

 The last option does not justify 4 tickets! (#450, #483, #543, #661)
 Unless anyone objects, I'm going to merge these all into #483.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/661#comment:4>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid


More information about the tahoe-dev mailing list