[tahoe-dev] Change the parameters(K-N) when using

[David-Sarah Hopwood]

On 2011-02-28 19:12, Greg Troxel wrote:
> 
> David-Sarah Hopwood <david-sarah at jacaranda.org> writes:
> 
>> 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.
>> Currently I think the easiest way to do that is to copy a directory tree
>> from the grid to a local filesystem and then copy it back (to a new directory
>> on the grid), then delete the original tree and allow its shares to expire.
>>
>> (Note that 'tahoe cp' directly from one grid directory to another will not
>> have the desired effect, because the new tree will link to the old immutable
>> files.)
> 
> So I wonder (as statements...):
> 
>   The fact that cp doesn't produce an output with encoding matching the
>   current config is a bug.  It's ok to reuse conforming immutable files,
>   but not to violate the expected postcondition.

I agree. Filed as <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1373>.

>   repair should have an option to consider an object unhealthy if the
>   encoding either doesn't match, or is weaker than (or ?) the current
>   config.  This is harder than regular repair because the URI will
>   change so it really needs to be "when deep repairing a directory,
>   objects in the directory might need recoding" - and then it gets
>   scary.

I think it would be confusing to refer to this deep-rebalancing operation
as a variant of repair. Remember that there may be links from elsewhere
into the directory tree being repaired. So, we need to repair the
existing objects (files or directories) without moving them, even if we
*also* upload new objects with the new encoding parameters.

Note that if we upload a new *mutable* object and relink a parent directory
entry to it, that can't be a semantically transparent operation (because
any link from elsewhere will no longer be aliased to the same object).

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110228/1d3be0d8/attachment.pgp>