Citation: V. Srinivasan and J.C. Mogul, "Spritely NFS: Experiments with Cache-Consistency Protocols", Proceedings of the 12th ACM Symposium on Operating Systems Principles, December 3-6, 1989, pp. 45-57. * Summary A comparison of the file-system cache consistency mechanisms in NFS and Sprite is completed. In addition, NFS is modified to use Sprite's mechanisms to determine if Sprite's better performance is strictly due to it's policy or is influenced by other parts of Sprite. Dramatic improvements are shown for a few benchmarks using Spritely NFS versus NFS. * NFS Cache Consistency NFS uses a stateless server model, and thus has a stateless, probabilistic consistency scheme. Without information on which clients are using a particular file, NFS cannot guarantuee cache consistency. Instead, clients periodically query the server to see if a file has been modified. The checking interval is a compromise between performance and consistency, but all opens require a check. All changes to a file by a client are written- through to the server, since a client cannot know if another client is caching the same file. The write-through policy is advantageous for crash recovery, but has two main disadvantages. The first disadvantage is that studies have shown that typical UNIX file access patterns are composed of very little sharing, and thus caching on a single client is sufficient rather than doing a server disk-access for every write. The second disadvantage is that applications are forced to run synchronously with the server disk in the presence of writes, unless a daemon is used by an NFS implementation to handle writing the data through to the server. In either case, all pending write-throughs are finished when the file is closed. * Sprite Cache Consistency Sprite maintains a stateful-server, and keeps track of explicit open and close operations. Using the information from opens, the Sprite file server can know all the current clients of a file and the type of access they intend to perform. When the file is not write-shared, it can be cached on a client without consistency checks and write-back may be used. A client is informed of the cacheability of the file in response to an open request. Whenever a file becomes write-shared, caching is disabled on the writer and readers, by issuing callbacks to current readers and not allowing the writer to cache the file. Thus, write-sharing causes not only write-through, but reads go to the server as well. * Potential Advantages of the Sprite Model Sprite's consistency model guarantuees consistency at all times, while NFS only provides a consistency guarantuee in the case of sequential write-sharing, where a file is opened for read only after the writer closes it. Sprite uses write-back except in the case of write-sharing, which occurs very infrequently. Write-back improves performance by allowing overlapping of computation and I/O, and by delaying writes long enough that some writes need not ever go to the server (e.g., short-lived temporary files). Write-back also may improve response time by reducing the total number of server writes and eliminating the extra consistency probes, at the cost of requiring explicit open and close operations. * Spritely NFS Two new RPC calls were made available to clients, open and close. Open takes a filehandle and a flag indicating its write-intentions. The server returns a flag indicating if the file can be cached, as well as the latest and previos version numbers associated with the file. The version number is incremented by the server whenever the file is opened for write access. On reads, a client's cached version of the file is valid if it matches the server's latest version. For writes, the cached version is valid if it matches the previous version (since the version number was incremented for the current write). The server also returns the attributes of the file in response to the open. Close takes the same parameters as open, since the writeFlag must be passed to the server in order to differentiate multiple opens by the client on the same filehandle. The use of callbacks requires Spritely NFS clients to provide an RPC service, and requires servers to be multi-threaded (to handle an open request, callbacks, and servicing write-backs all at the same time). Both data and attributes are cached on clients when the file is not write- shared, and both are fetched from the server when it is. The state maintained by the SNFS server includes a hash table of entries for each open file and each closed file whose last writer may still have cached blocks. Each entry consists of the file handle, current version number, current state (e.g., read-only or write-shared), and a list of client information blocks. * Performance A performance comparison of NFS and SNFS was performed using the Andrew Benchmark. Three configurations were used: (1) all files on local disk, (2) data files remote w/ local temp files, and (3) both data and temp files remote. In all configurations, the compiler resided on the same file system as the data, and all other UNIX utility programs were available locally. Results show SNFS is 25% better on Copy phase, and 20-30% better on the Make phase. NFS is about 5% better on the ScanDir and ReadAll phases. Overall, SNFS completes the benchmark 15-20% faster than NFS. With respect to RPC operations, SNFS is slightly more expensive when temp files are local, but has 42% less data transfer operations than NFS when temp files are remote (but only 6% few operations overall). Interestingly, the improvements of SNFS over NFS were not as much as Sprite over NFS.