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

[David-Sarah Hopwood]

On 19/10/12 00:09, Zooko Wilcox-O'Hearn wrote:
> Okay, great! I was very confused to think that querying and changing
> leases would be a long expensive process. That's the whole *point* of
> leasedb is to make that fast and reliable. Duh.
> 
> I agree that the protocol you sketched out in your email would work,
> including that the client can wait for confirmation that it worked and
> retry it if it didn't (such as if the server failed at any point).
> 
> It kind of sounds like with this current revision of the scheme you
> don't really need to crawl over all the shares for the purpose of
> garbage collection.

Yes, that's true. I hadn't thought about that very hard before this
discussion; I was trying to limit design changes to only those strictly
needed to support leasedb. But yes, maintaining a queue of shares-to-delete
would be more efficient (in terms of deleting garbage more quickly).

> You still need to crawl in order to build an index
> of shares for the first time (i.e., when you first turn on leasedb, or
> if your leasedb gets destroyed or corrupted) and even if you have a
> leasedb, you might still want to crawl in order to discover
> externally-imported shares, and I *guess* it might be useful to crawl
> in order to discover that shares have been externally removed, but
> there's no need to crawl in order to expire or garbage-collect shares,
> is there?

No. That's the minimal change from the existing code, though. I don't
think there's any overall simplification available unless we could remove
crawlers *entirely*, which I don't think we can do. We can always optimize
garbage collection later.

-- 
David-Sarah Hopwood ⚥

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