Path: utzoo!attcan!uunet!lll-winken!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent
From: brent@terra.Eng.Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.nfs
Subject: Re: NeFS
Keywords: NeFS, NFS
Message-ID: <138222@sun.Eng.Sun.COM>
Date: 2 Jul 90 17:54:46 GMT
References: <1075@cluster.cs.su.oz>
Sender: news@sun.Eng.Sun.COM
Lines: 85

In article <1075@cluster.cs.su.oz>, bruce@basser.cs.su.oz.au writes:
> Each RPC consists of both a call and a reply message.
> Thus 10 messages are transmitted on the network in
> the "chmod()" example above.
> With a conceptually simple change to the NFS protocol it might
> be possible to reduce this number from 10 to 2 by
> providing a new RPC which expected a file handle and a
> list of pathname components as its initial arguments (rather
> than just a file handle):
> 
> 	nsetattr(fh0, "etc", "rc0.d", "a", 0, .., mode, ..)
> 

Actually things aren't quite that bad with most Unix client
implementations.  The client's directory name lookup cache
(dnlc) will cache the intermediate directory name translations.
If it's the first reference to a path you will get stuck
with having to do separate over-the-wire lookup operations
per pathname component.  NFS gives you no choice here.

We have messed with the idea of having a generalized NFS LOOKUP
operation that would take a vector of names - components in a
pathname.  This comes under the heading of "Multi Component Lookup"
(MCL).  This is achievable via the current vnode interface - no new
system calls are required - our implementation of RFS under vnodes
already uses MCL.  HOWEVER - here's the crunch: in typical
filesystem traffic MCL is hardly ever useful (my observation).  The
dnlc does a pretty good job of avoiding long strings of client
pathname lookups.  Adding MCP to a protocol rev of NFS would be
"nice" but it comes at a cost of increasing the complexity of the
protocol for little added benefit - the RISC vs CISC that Vernon
Schryver referred to.  Herein is the advantage of a protocol like
NeFS:  it doesn't *explicitly* support MC but you can easily
*express* MCL in it.

A better example perhaps is something akin to Morris Meyer's. 
I have "ls" aliased to "ls -F".  This appends a character to
names in the listing to indicate their type e.g. "/" means 
directory, "*" means executable, "@" means symlink.  These are
derived from the file attributes.  File attributes are not
returned by NFS's READDIR.  The client is forced to LOOKUP
every name in the directory to get its attributes e.g. in
my home directory with ~80 names I generate 80 over-the-wire
LOOKUP's to the server.  In large directories it's noticeable
faster just to "/bin/ls" and skip the NFS overhead imposed by
generating the funny little characters.

It gets worse if you use a window-based file manager as used
in MacOs, MS Windows, NeXT & OpenWindows.  It's common to
pop open a folder and view the files as labelled icons.  The
labelled icons are derived either by inspection of file attributes
or by reading some file data.  Here interactive response can
suffer noticeably if access is through the NFS protocol

> In the appendix to Sun's Draft NeFS document ("The Network Extensible
> File System Protocol Specification"), there are 3 examples given.
> The second ("Read a directory") could be derived fairly directly from
> the "getdents()" system call.  However, neither of the other two
> ("Determine disk usage in bytes" and "Copy a file")
> can be generated by any single existing unix system call.

Yes, NeFS sets out to be a distributed filesystem protocol - not
a specifically a Unix protocol.  The examples are intended to
demonstrate the power of the protocol - not what's narrowly expressible
via the current vnode interface.

> The extreme generality of NeFS and the above two examples suggest
> that Sun is proposing not only a new underlying network file system
> protocol but also a new unix system call interface.

It will take years for any new distributed filesystem protocol to
become as ubiquitous as NFS.  Nobody can predict the changes to
interfaces that utilize the protocol - Unix system calls and the
vnode interface are just one example.  Assuming that such a protocol
becomes generally accepted, it should be able to evolve with changes
in OS and filesystem design.

We're not proposing a new system call interface, just a protocol that
won't stand as a barrier to the network extension of changes to
the filesystem interface - no matter who implements it.
--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 uucp: sun!bcallaghan
			 phone: (415) 336 1051