🚀 go-pugleaf

In article <1992Dec30.155939.13344@spectrum.xerox.com> weltman@adoc.xerox.com writes:
>
>  I followed the initial discussion in this group about RPC, TCP, and
>UDP with great interest. At about the same time, a friend did a series
>of benchmarks in a network of Sparcstation 2's, to compare the file
>transfer performance using TCP sockets, NFS (write to remote-mounted
>disk), and RPC using TCP. The files were large (around 2 MB or larger).
>RPC using TCP was slightly slower than straight sockets using TCP, as
>expected. What was surprising was that it was so slow to just do a
>large write to the open file descriptor of a remote mounted file.
>
>Why is NFS so slow?

NFS is "stateless", which means that each "write" from the client side
will result in an open/write/close on the server.  The opens/closes slow
it down quite a bit over the file-transfers you were comparing it to.

-- Tad

>NFS is "stateless",

True (modulo debate about the meaning of "stateless").

>which means that each "write" from the client side
>will result in an open/write/close on the server.  The opens/closes slow
>it down quite a bit over the file-transfers you were comparing it to.

False, at least in the UNIX NFS servers I've seen.  In those, there
aren't any "open"s or "close"s done by the NFS server.  Instead, the NFS
server takes the file handle it was given by the client, asks the
underlying file system to cough up a vnode (or moral equivalent, in
systems that decided to be perversely different) for the file with that
file handle, asks the underlying file system to perform the write (or
whatever) on the file referred to by the vnode, releases the vnode if it
was held, and returns the result.

The "get a vnode" and "release the vnode" operations may be what you're
thinking of as the "open" and "close" operations, but they are *NOT*
what's slowing the writes down; they're relatively cheap, especially if
the file system's data for the vnode in question (inode, or whatever) is
cached.

The writes are slowed down by being done synchronously; see the summary
of responses to the original question for a more detailed discussion.

guy@Auspex.COM (Guy Harris) writes:

>>NFS is "stateless",

>True (modulo debate about the meaning of "stateless").

>>which means that each "write" from the client side
>>will result in an open/write/close on the server.  The opens/closes slow
>>it down quite a bit over the file-transfers you were comparing it to.

>False, at least in the UNIX NFS servers I've seen.  In those, there
>aren't any "open"s or "close"s done by the NFS server.  Instead, the NFS
[stuff describing UNIX implementations deleted]

On Stratus NFS the NFS server regularly opens the file. This is indeed a very
slow operation that involves directory access. To make things usable the
NFS server doesn't close files immediately after each write or read. Instead
the files are kept open for a certain period. The time files are kept open is
an installation parameter for the NFS server.  It is normally 30 seconds
or so. This means that a write/read benchmark that writes/reads a stream
of blocks as fast as it can incurs only one open.

Gijs Mos
gjm@dasc.nl
#include <stddisclaimer.h>       This might not be the view of my employer.