lease paper

A lease is a contract that gives its holder specified rights over property for a limited period of time. In the context of caching, a lease grants to its holder control over writes to the covered datum during the term of the lease, such that the server must obtain the approval of the leaseholder before the datum may be written. When a leaseholder grants approval for a write, it invalidates its local copy of the da-202mm.
A cache using leases requires a valid lease on the datum (in addition to holding the datum) before it returns the datum in response to a read, or modifies the datum in response to a write. When a datum is fetched from the server (the primary storage site of the datum), the server also returns a lease guaranteeing that the data will not be written by any client during the lease rerm unless the server first obtains the approval of this leaseholder. If the datum is read again within the term of the lease (and the datum is still in the cache), the cache provides immediate access
to the datum without communicating with the server.After the lease expires, a read of the datum requires that the cache first extend the lease on the datum, updating the cache if the datum has been modified since the lease expired. When a client writes a datum, the server must defer the request until each leaseholder has granted approval or the term of its lease has expired. 
We limit ourselves here to write-through caches, for doing so simplifies the explanation; extending the mechanism to support non-write-through caches is straightforward. Write-through gives clean failure semantics: no write that has been made visible to any client can be lost; applications must otherwise be prepared to recover from lost writes. Though the cost of write-through for file caches is considered prohibitive by some [ 16], the cost can be largely eliminated by giving special handling to temporary files [9,24], since they receive the majority of writes. To illustrate the operation of a file cache using leases, consider a diskless workstation being used for document production. When the workstation executes latex for the first time, it obtains a lease on the binary file containing latex for a term of (say) 10 seconds. Another access to the same file 5 seconds later can use the cached version of this file without checking with the file server. An access to this file after the lo-second term has expired requires the cache to check with the server. When a new version of latex is installed, the write is delayed until every leaseholder has approved the write. If some host holding a lease for this file is unreachable, the delay continues until the lease expires. In the preceding example, the relevant reads and writes are not limited to operations on the contents of the file. In order to support a repeated open, the cache must also hold the name-to-file binding and permission information, and it needs a lease over this information in order to use that information to perform the open. Similarly, modification of this information, such as renaming the file, would constitute a write.
Short lease terms have several advantages. One is that they minimize the delay resulting from client and server failures (and partitioning communication failures). When the server cannot communicate with a client, the server must delay writes to a file for which the failed client holds a lease until that lease expires.] When a server is recovering after crashing, it must honor the leases it granted before it crashed. This is most easily done if it remembers the maximum term for which it had granted a lease, and it delays writes to all tiles for that period, effectively increasing the time to fully recover by the maximum term.
Alternately, the server can maintain a more detailed record of leases on persistent storage, but the additional I/O traffic is unlikely to be justified unless terms of leases are much longer than the time to recover.
Short leases also minimize the false write-sharing that occurs. False sharing refers here to a lease conflict when no actual conflict in file access exists. Speciftcally, false sharing occurs when a client writes to a file which is covered by a lease held by another client when the other client is not currently accessing the tie. False sharing introduces the overhead of a callback to the leaseholder(s) (thereby delaying the requesting client and loading the leaseholder and server) in a situation where without leases there would be no conflict. In the extreme, a lease term should be set to zero if a client is not going to access the file before it is modified by another client.
Finally, short lease terms reduce the storage requirements at the server, since the record of expired leases could be reclaimed. However, the storage overhead for the server to keep track of the leases it has granted is modest. The server requires a record of each leaseholder’s identity and a list of the leases it holds; each lease requires only a couple of pointers. For a client holding about one hundred leases, the total is around one kilobyte per client. Even if this were a problem, it could be reduced by recording leases at a larger granularity, so that each client holds few leases, at the expense of some increase in contention. We show later how the per-client record can be eliminated for the most common class of widely-shared files. Longer-term leases are significantly more efficient both for the client and server on files that are accessed repeatedly and have relatively little write-sharing. This may be observed in the Andrew file system project [lo], which went from using a lease term of zero in the prototype to effectively a lease term of infinity in the revised version.’ The next section presents an analytic model of lease performance and detemrines appropriate lease terms using parameters based on data from the V distributed system.