Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS
Keywords: NeFS, NFS
Message-ID: <63209@sgi.sgi.com>
Date: 1 Jul 90 19:23:20 GMT
References: <1075@cluster.cs.su.oz>
Sender: vjs@rhyolite.wpd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 36

In article <1075@cluster.cs.su.oz>, bruce@basser.cs.su.oz.au writes:
...
> 
> chmod("/n/etc/rc0.d/a", mode);	getattr(fh0)
> 				lookup(fh0, "etc")
> 				lookup(fh1, "rc0.d")
> 				lookup(fh2, "a")
> 				setattr(fh3, .., mode, ..)
> Each RPC consists of both a call and a reply message.
> Thus 10 messages are transmitted on the network in
> the "chmod()" example above.
...

If the client does any caching, as would expected if the client NFS
implementation were at all related to a disk file system implementation,
then you would not expect 10 RPC's to be needed for the vast majority of
all such system calls.  For one thing, one (either a person or a program)
rarely fiddles with /a/b/c/d/e/foo without also fidding with /a/b/c/d/e/bar
at about the same time, so that the full attributes including
rnode/vnode/whatever are likely to be present when you use a long pathname.

A quick look at `nfsstat` on machines around here validates that
intuition.  (NFS is used quite heavily for Silicon Graphics software
development, as well as for usenet-news and other stuff).  I see far more
getattr()'s, both client and server, than lookup()'s.  One often sees more
getattr()'s than read()'s, but I suspect that is a result of the familiar
3/30 second cache timeouts.

The RISC trick of making the common stuff lean, mean and fast, and the
uncommon stuff only functional should be used in file system design.
One should have only those remove file system operations that are
either absolutely primitive or sufficently common.


Vernon Schryver
vjs@sgi.com