[tahoe-dev] How do lease renewal and repair work?

[Shawn Willden]

On Tue, Jan 11, 2011 at 12:33 PM, Brian Warner <warner at lothar.com> wrote:

> Servers should reject lease add/renewal requests when in readonly mode
>

I can see value in allowing for read-only storage servers that intend to
continue serving the shares they have, so I think lease renewals should be
accepted.


> When repairing a file, the client should not be happy until all N shares
> have a lease that will last at least as long as the client's configured
> lease-duration value. We might need a "please tell me how long lease XYZ
> will last" request. If a renewal request is rejected, and the existing
> lease will expire too soon, the repairer should upload additional shares
> to other servers.
>

Or perhaps it would be simpler if rather than asking how long a lease will
last, the client should simply request a lease renewal out to the desired
date.  If the renewal is rejected, then the repairer would upload additional
shares to other servers regardless of when the lease will expire.  Perhaps
it should then send a message cancelling the expiring lease.

That sounds like a great approach. Maybe "retired"/"retiring"?
>

"Retiring" is probably a better name.


>  We've also kicked around the idea that storage servers should be
> able to "abandon ship" on their own: upload their shares directly to
> other servers (do the permuted-list thing on their own, remove
> themselves from the result, find the best place to evacuate the share
> to, upload the share, then delete their local copy). This could only
> work for immutable shares, since the mutable write-enabler gets in the
> way as usual, and it might interact weirdly with Accounting (the old
> server would effectively be "paying" for the new share until the real
> clients established new leases and took over ownership). But it'd
> probably be more efficient: the share already exists, so no need to
> re-encode the file.


That would be nice, but more complex.

-- 
Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110111/46390966/attachment.html>