... Storage

This research was supported in part by NSF grants CCR-9984030, EIA-0080119 and a gift from IBM Corporation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... cache.

Depending on the exact cache contents, the warm cache network message overhead can be different for different caches. We carefully choose the system call parameters so as to emulate a ``reasonable'' warm cache. Moreover, we deliberately choose slightly different parameters across system call invocations; identical invocations will result in a hot cache (as opposed to a warm cache) and result in zero network message overhead for many operations.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... call.

The access RPC call was first introduced in NFS V3. Our Ethereal logs did not reveal its use in the Linux NFS v3 implementation, other than for root access checks. However, the NFS v4 client uses it extensively to perform additional access checks on directories and thereby incurs a higher network message overhead.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... tandem.

The extra overhead of access is probably an artifact of the implementation. It is well-known that the Linux NFS implementation does not correctly implement the access call due to inadequate caching support at the client [7]. This idiosyncrasy of Linux is the likely cause of the extra overhead in NFS v4.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... systems.

The Transaction Processing Council does not allow unaudited results to be reported.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.