[tahoe-lafs-trac-stream] [Tahoe-LAFS] #864: Automated migration of shares between storage servers

[Tahoe-LAFS]

#864: Automated migration of shares between storage servers
-------------------------+-------------------------------------------------
     Reporter:  kpreid   |      Owner:
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  major    |    Version:  1.5.0
    Component:  code-    |   Keywords:  preservation accounting leases
  storage                |  anti-censorship
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Old description:

> There should be a way to have a storage server automatedly move some or
> all of its shares to other storage servers. Right now this can be done
> only as a tedious manual process.
>
> Use cases:
>  1. A storage server is being decommissioned; the shares would otherwise
> be entirely lost.
>  2. A storage server needs some disk space freed up for other purposes.
>
> If it finds that another storage server has the same share (can be caused
> by repair), it could just be deleted locally.
>
> Refinement:
>
> Furthermore, since the storage server knows the server selection
> algorithm, it can choose to distribute particular shares to storage
> servers which occur early in the permuted peer order, so that the time to
> retrieve the shares will be better on average than it would have been if
> all this server's shares were moved uniformly to an arbitrarily-selected
> server.
>
> In fact, if this cleverness is implemented it might be worth doing under
> normal conditions, to redistribute shares uploaded to the "wrong" peers
> because the right (early-searched) ones were unreachable at the time.
> (The interaction of this with #573 would need consideration.)

New description:

 There should be a way to have a storage server automatedly move some or
 all of its shares to other storage servers. Right now this can be done
 only as a tedious manual process.

 Use cases:
  1. A storage server is being decommissioned; the shares would otherwise
 be entirely lost.
  2. A storage server needs some disk space freed up for other purposes.

 If it finds that another storage server has the same share (can be caused
 by repair), it could just be deleted locally.

 Refinement:

 Furthermore, since the storage server knows the server selection
 algorithm, it can choose to distribute particular shares to storage
 servers which occur early in the permuted peer order, so that the time to
 retrieve the shares will be better on average than it would have been if
 all this server's shares were moved uniformly to an arbitrarily-selected
 server.

 In fact, if this cleverness is implemented it might be worth doing under
 normal conditions, to redistribute shares uploaded to the "wrong" peers
 because the right (early-searched) ones were unreachable at the time. (The
 interaction of this with #573 would need consideration.)

--

Comment (by Lcstyle):

 Looking at 671 and I've suggested that this functionality would also
 address the issue of storage nodes that were looking to either shrink
 their offered storage capacity or shutdown altogether.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/864#comment:7>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage