[tahoe-dev] Storage Node Proactive Share Relocation

[Brian Warner]

On 5/11/11 11:13 AM, Greg Troxel wrote:
> 
> Nathan Eisenberg <nathan at atlasnetworks.us> writes:
> 
>> However, if you've got valid shares on that server, why not be able to
>> use them to regenerate shares?  In other words, have the storage node
>> reallocate its own shares before making them unavailable.

Yeah, you don't even have to regenerate anything, just copy. If your
server is going away, the easiest (computationally) thing to do is to
just copy your share to some other server before shutdown. Apart from
accounting, this is pretty easy: each server can compute the same
permuted-server-list that the original client does, then they can find
the best location for their soon-to-be-displaced share. Servers can
upload shares just as easily as clients (again, except for Accounting),
so they just write the share to a better place and then delete their own
copy.

> that's been discussed.  the notion would be to have the server place the
> shares it has with some other servers.
> 
> The hard parts are:
> 
>   respecting the share distribution policies of the share owners

Yeah, this is a place where the current "all policy is embedded in the
storage-index/UEB" algorithm helps a lot, and where more
complicated/flexible allocation schemes ("I want 'k' shares at Mom's
house, and at least k+1 shares in each datacenter, but no two shares in
the same chassis") are harder. It also suggests challenges with schemes
in which the same file might be distributed differently depending upon
who uploaded it.

(hm, but I guess that with servers-of-happiness, that's no longer true:
the server does not know the SOH value of the uploader, and thus cannot
determine whether the share-placement that they compute would satisfy
the uploader's SOH criteria. I think SOH checks are mostly binary:
happy/unhappy, so maybe it's not a big deal)

> 
>   dealing with accounting

In particular, (in our proposed-but-not-yet-implemented model) the
original uploader had some rights to consume space on the departing
server A. Server A needs to somehow convert those into rights to consume
space on-the-user's-behalf on the new server B. But we don't want server
A to be able to just consume space on B for themselves (unless
explicitly granted).

One approach we've talked about involves a separate "repair manager",
with rights of its own, and it takes responsibility for the relocated
share until the original uploader comes around and claims it. In
another, uploaders delegate some storage-authority ahead of time to each
server (it's an N^2 problem) to enable this "abandon-ship: all shares
must go" operation. So far we haven't really come up with something
satisfying.

fun stuff,
 -Brian