On Fri, Oct 12, 2012 at 4:29 PM, David-Sarah Hopwood <david-sa...@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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
