Introduction

Unlike more advanced Network File System (NFS) client implementations, such as those by Sun Microsystems for SunOS and Solaris, the Linux 2.0.x NFS client has few performance features. Only asynchronous read-ahead buffering and some rudimentary lookup attribute caching is performed. All writes are done synchronously, resulting in write speeds that can be as low as 25KB/sec,² and no caching of read data is performed.

Despite the design limitations of NFS (e.g., no tokens, push-on-close, and stateless servers) commercially-available clients achieve substantially better performance (on the order of MB/sec, not KB/sec) [Mic95]. This paper describes numerous performance improvements to the Linux NFS client which make a notable difference to the usability of NFS-mounted partitions for Linux users. Among these are:

Asynchronous write buffering.

Although the Linux 2.1.32 kernel introduced this feature, that kernel is still in development so its benefits are of no use to users who require the stability of a 2.0.x kernel. Our implementation integrates the asynchronous writing capabilities of the newer kernels into the 2.0.x kernel series (the original integration is the work of Jan Sanislo, oystr@cs.washington.edu).³

Caching of lookup RPC results.

The basic NFS client caches only the 64 most recent filename lookups, and searches linearly through that list. Since lookup remote procedure calls are so common [Mac91, p. 61], improvements to lookup caching can noticeably reduce network traffic and server load. Our implementation enlarges the lookup results cache to 511 elements and uses a hash-table instead of a linear list. This feature was largely implemented by Doug Zongker, dougz@cs.washington.edu.

Local disk caching of reads.

Many NFS exported directories contain a large number of files which are mostly read, and written only occasionally.⁴ Since many workstations have fast, large, often under-used local disks (see also Minnich's AutoCacher [Min93]), we implement read caching using the local disk as a large repository. We rely on the underlying file system to use delayed writes and its own caching to make writing to the cache efficient.⁵

We limit our implementation to use Version 2 of the NFS protocol [Mic89] instead of exploiting some of the possible benefits provided by Version 3 [Mic94] such as readdirplus and commit. We imposed this constraint because few NFS V3 servers exist, and the base Linux NFS implementation does not yet provide full V3 support.

To measure our performance improvements, we use the Andrews File System (AFS) benchmark suite [HKM⁺88] along with some larger test cases, and some micro-benchmarks. In addition to measuring real time, we count the number of remote procedure calls of various types. Since RPCs are so expensive (especially on a slow network), they tend to dominate the performance of an NFS client. Our goal has been to reduce RPCs.

The next section discusses the design and overall architecture of our implementation. Section describes the details of the asynchronous writing and lookup caching implementations, and section explains the implementation of read caching. Section describes how we measured the performance of our implementation, and shows the results of our benchmarks. Finally, sections and describe some possibilities for future work and summarize the findings of this project.