Where to specify lease time

[lvo]

I read the architecture document about the concept of peers granting lease time for each file that it holds. Suppose I want a peer to grant an indefinite lease time, how would I specify that ?

Thanks. Lu

[zooko]

Dear lvo:

If I try to answer this question, will you submit a patch to the relevant docs which will make the answer apparent to the next person who comes after you, who is wondering the same thing?

Thanks,

Zooko

[lvo]

I certainly will.

Thank you. Lu

[warner]

So at this point, we have not yet implemented leases. If you take a look at source:roadmap.txt, under the 'Storage' section, the 'v5' milestone is where we'll implement that. What we do have at the moment is a StorageServer? which will grant a lease if there is enough space available, but the leases it grants never expire.

When we build real, expiring leases (probably within the next month), there will probably be a control file on each node that establishes the period of the lease (which we expect to default to be one month). It's not yet clear to me if there is a good reason to make this configurable.. I'd be eager to hear your thoughts on this. I'm currently thinking that the client won't ask for a specific duration when it requests a lease, but again I'd like to hear arguments to the contrary.

We have to figure out deletion of files and probably the FileChecker? before we can really afford to let leases expire, since those are the mechanisms to keep files alive despite their leases expiring.

[lvo]

I am interested in using tahoe to serve my own purpose, which is not file sharing but as a permanent archive of data with the benefit of high availability and failure tolerance. Therefore, I would want to set a lease time to forever. Not only that, but I would like it if there is a way to re-establish the data of the failed peer so as to preserve the possibility that a really old file is lost due to successive failure of original peers. If you think tahoe could potentially serve my purpose ?

Thanks Lu

[lvo]

A couple of typos in my recent post. "preserve" should be "prevent" "If you think" shouldd be "Do you think"

[zooko]

So recently (citation needed), we've been thinking that instead of having a lease time for each share, we should use an incref/decref strategy for each share, and uses leases to timeout *accounts* who are no longer in good standing.

In the meantime, the current version (which will become v0.6 tomorrow), does not delete shares in any case.

The second thing you mention -- re-establishing the data of the failed peer is on our source:roadmap.txt -- it is the category named "Checker/Repairer?". We consider it to be a required feature that we just haven't gotten to yet.

[zooko]

The "specifying lease time" or otherwise managing the resource usage is part of the big upcoming task which is in Milestone 0.7.0. See ticket #119, and a bunch of other tickets in the Milestone 0.7.0. Adding this ticket to Milestone 0.7.0.

[warner]

just an update, we've got code to write out these leases, and they use a default 1 month lease time. That code is in src/allmydata/storage.py . So we're closer to having a place for the admin to express a preference on this one.

I think the way to go is for a file named 'lease_duration' to be found in the node's basedir. If present, it should contain a number of seconds for the default duration, or the string "unlimited" if these leases should never expire.

Or maybe "lease_timeout" ? "lease_period"? "lease_expiration_time"?

[zooko]

We're focussing on an imminent v0.7.0 (see ​the roadmap) which hopefully has #197 -- Small Distributed Mutable Files and also a fix for #199 -- bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

[zooko]

We need to choose a manageable subset of desired improvements for [ ​http://allmydata.org/trac/tahoe/milestone/0.7.1 v0.7.1], scheduled for two week hence, so I'm bumping this one into ​v0.7.2, scheduled for mid-December.

[davidsarah]

This seems to be documented in source:docs/garbage_collection.txt

source:docs/architecture.txt#L306 should probably just be changed to point to garbage_collection.txt and to remove any out-of-date information, and then this bug can be closed, no?

[zooko]

David-Sarah: yes I believe you are right.

[zooko]

Fixed! Thanks! :-) The most recent detail was fixing the docs as suggested in comment:13; this was accomplished by d3d1293d2fee8b62.