On 2011-02-28 19:12, Greg Troxel wrote: > > David-Sarah Hopwood <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
