[tahoe-dev] use case request for accounting/leasedb

[Zooko Wilcox-O'Hearn]

On Fri, Oct 12, 2012 at 4:29 PM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
>
>> The only difference between this and the current scheme is that the
>> storage server will never do that on its own — it only does it when
>> you tell it that it is okay to do it.
>
> Okay, so I think this means that lease expiry -- the operation of removing
> leases that are past their expiration date -- needs to be triggered separately
> from deletion of unleased shares.
>
> If lease expiry can be triggered independently per account, then that
> becomes the "okay to expire" operation. The accounting crawler will only
> delete shares with no lease on any account, and will not itself expire
> leases.
>
> Does this seem like it supports what you want?

Almost, but I don't think that will be good enough to implement
everything we'll need here. I think it probably *would* be sufficient
if you could scan and update all the shares (to remove Alice's lease)
instantaneously.

But, the process of scanning all shares could take a long time, it
could even take weeks to finish, and is expensive in terms of disk
usage (seeks, not bandwidth), or cloud storage API requests (number of
requests, not bulk upload/download). So the first issue with the
proposal above is, what happens if I tell you "Okay now you can remove
any shares of mine which I haven't marked.", and you start doing that,
and then you crash and restart before you finish doing it? It isn't
okay for you to leave my shares in place and keep charging me for
them, so you'd better write it down that you intend to do that so
you'll remember to get back to it.

Second, what if you are in the process of looking for shares that are
expired (for me), and I say "Okay! I'm about to mark all my *current*
documents and then I want you to stop charging me for all others.
Ready? Here I go!".

So, in other words, it might take you longer to find all my shares
than it takes me to change my mind and choose a new subset of shares
that I'm willing to continue paying for.

I think these are realistic constraints (in terms performance of the
backend) and requirements (in terms of what customers would accept),
so I think we might need to rethink whether we need to extend the
leasedb (for example, to write down who said to set a mark, and when
they said it, and perhaps even to link the subsequent sweep to that
*particular* mark among all marks that they've ever set?).

Regards,

Zooko