On 2/28/11 11:06 AM, David-Sarah Hopwood wrote:
>
> Rebalancing, i.e. changing the parameters of existing files and
> putting shares in the optimal places, is less automatic than we would
> like it to be.
One nitpick: so far, we've been using the word "rebalance" to mean "move
existing shares around to make them live on the correct server". You
would rebalance to improve diversity (e.g. when there weren't enough
servers during the original upload to get one-share-per-server, but new
servers have joined since then, and you want to use them), or to improve
download performance (if the shares are in their "right" place, the
downloader won't have to search very far for them). "Repair" is mainly
about regenerating shares that were lost for whatever reason, but should
really include rebalancing too. After a file has been
repaired+rebalanced, the shares should be in exactly the same places as
they would be after a successful initial upload.
"Re-encoding" is very different, and could result in a new URI/filecap.
As David-Sarah pointed out, the only way to get that right now is to
move the file out of tahoe altogether and then copy it back in ('tahoe
get FILECAP | tahoe put', for example). We should probably add an option
to 'tahoe cp -r' that would bypass the re-use-immutable-file trick, to
make it easier to do a deep-reencode.
The important point is that repair/rebalance makes existing URI/filecaps
work better, not create new filecaps with different properties. I'd like
to keep using those words for that purpose, and use a different word for
something that makes new filecaps.
nitpickily,
-Brian
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
