[tahoe-dev] Storage Node Proactive Share Relocation

[Zooko O'Whielacronx]

On Wed, May 11, 2011 at 12:36 PM, Brian Warner <warner at lothar.com> wrote:
>
> Yeah, you don't even have to regenerate anything, just copy.

This is true for immutable shares, but not for mutable shares. Mutable
shares include a token called the "write authenticator" which is used
by the client to prove that it has the authority to upload a new
version of the mutable share. When a client shows a write
authenticator to a storage server, we don't want the owner of that
storage server to be able to turn around and act as a client and show
that write authenticator to another storage server in order to be able
to overwrite a mutable share from the same file stored on that other
storage server. Therefore, the write authenticator is unique for each
storage server. Therefore, if you transfer a mutable share to a new
storage server, the client will no longer be able to overwrite that
mutable share with new version, although it will still be able to read
that mutable share.

One of the desiderata for the New Cap Design [1] is to eliminate this
inconvenience and make mutable shares just as portable as immutable
shares. This could be accomplished by requiring the storage server to
verify a digital signature on the client's write attempt instead of
checking a secret token from the client. Whether that will be worth
the computational cost, the complexity in the storage server's
implementation, and so on remains to be seen.

(Brian knows all this, and in fact he'll probably be able to spot an
inaccuracy or omission in what I've written, so the above is addressed
to everyone else other than Brian.)

Regards,

Zooko

[1] http://tahoe-lafs.org/trac/tahoe-lafs/wiki/NewCapDesign