[tahoe-dev] Accounting, 2010 edition

[Brian Warner]

On 12/20/10 7:01 PM, David-Sarah Hopwood wrote:
> On 2010-12-20 22:16, Brian Warner wrote:

>> The other API would be used in a similar way, right after you build a
>> manifest, but it would mean "immediately cancel all my leases on
>> shares that weren't in the manifest". This would even be safe if only
>> you could lock your directory tree against changes, build a manifest,
>> issue the batch-cancel, then finally unlock the tree. Otherwise you
>> might be telling the server to cancel something that you actually
>> care about (but started caring about too late for it to be included
>> in the manifest).

> Make the cancel operation a long-running operation (using an
> ophandle). Then it can cancel all shares that were present before the
> operation started and that are not in the manifest.

> Actually it would be a foolscap reference rather than an ophandle,
> since this operation would be part of the storage server protocol,
> presumably?

Hm, I'm not following. It's been a year or two since I studied this, but
I remember concluding that "locking a directory tree" was completely
infeasible. I think the issue was a race between adding a link (to some
existing file) into one part of your directory tree versus removing the
last link from some other part of the tree. In particular, I'm concerned
about client#1 modifying some part of the tree while client#2 is trying
to build the manifest.

If the directory structure were visible to storage servers (i.e. they
knew exactly what the references were, even if they didn't know the
contents of files or the childnames in directories), they might be able
to help with reference counting. Not only would we prefer to not let
them see that shape, the fact that shares are distributed over multiple
servers means that it wouldn't work: server A might have shares for
<root> and <root/foo/bar>, but not for <root/foo>.


cheers,
 -Brian