<div class="gmail_quote">On Tue, Jan 11, 2011 at 12:33 PM, Brian Warner <span dir="ltr"><<a href="mailto:warner@lothar.com">warner@lothar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Servers should reject lease add/renewal requests when in readonly mode</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">When repairing a file, the client should not be happy until all N shares<br>
have a lease that will last at least as long as the client's configured<br>
lease-duration value. We might need a "please tell me how long lease XYZ<br>
will last" request. If a renewal request is rejected, and the existing<br>
lease will expire too soon, the repairer should upload additional shares<br>
to other servers.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">That sounds like a great approach. Maybe "retired"/"retiring"?</div>
</blockquote><div><br></div><div>"Retiring" is probably a better name.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"> We've also kicked around the idea that storage servers should be</div>

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