home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!auspex-gw!guy
- From: guy@Auspex.COM (Guy Harris)
- Newsgroups: comp.client-server
- Subject: Re: NFS and RPC
- Keywords: NFS,RPC
- Message-ID: <16274@auspex-gw.auspex.com>
- Date: 7 Jan 93 05:40:48 GMT
- References: <1992Dec30.155939.13344@spectrum.xerox.com> <1ig6ltINNe2d@shelley.u.washington.edu>
- Sender: news@auspex-gw.auspex.com
- Organization: Auspex Systems, Santa Clara
- Lines: 25
- Nntp-Posting-Host: auspex.auspex.com
-
- >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.
-