Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!metro!cluster!bruce@basser.cs.su.oz.au
From: bruce@basser.cs.su.oz.au
Newsgroups: comp.protocols.nfs
Subject: NeFS
Summary: even less like unix?
Keywords: NeFS, NFS
Message-ID: <1075@cluster.cs.su.oz>
Date: 29 Jun 90 16:15:25 GMT
Sender: news@cluster.cs.su.oz
Reply-To: bruce@basser.cs.su.oz.au
Lines: 117

Just a brief interruption to the PC-NFS exchanges ..

NFS is a widely used network file system protocol.  Perhaps it is
most widely used between unix systems.  NFS is also used between
PC's and unix systems.  Let's leave aside its application to PC's
and consider only its use between unix systems.

Under unix, an NFS client process waits while its system call
is translated into 1 or more remote procedure calls (RPC's)
which are then executed on an NFS server.  Once remote execution
has completed the results are returned to the waiting process
which is then allowed to continue.

Here are some example translations (where "/n" is an
NFS mount point and the fh's are file handles):

System Call			Generated RPC(s)
-----------			----------------
stat("/n", &statb);		getattr(fh0)

stat("/n/etc", &statb);		getattr(fh0)
				lookup(fh0, "etc")

stat("/n/etc/rc0.d", &statb);	getattr(fh0)
				lookup(fh0, "etc")
				lookup(fh1, "rc0.d")

stat("/n/etc/rc0.d/a", &statb);	getattr(fh0)
				lookup(fh0, "etc")
				lookup(fh1, "rc0.d")
				lookup(fh2, "a")

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.
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, ..)

Continuing with this approach we can arrive at a revised NFS protocol
which sends exactly one RPC for each client process system call.
However, we can't do better than this as long as we continue
to use the standard unix system call interface.
For example, the following pseudo-code sequence (which
might be from cpio, tar or restore):

	fd = creat("/n/a", mode);
	write(fd, "A", 1);
	close(fd);
	chown("/n/a", uid, gid);
	utime("/n/a", tp);

must generate at least 5 x 2 = 10 network messages.
There may well be an RPC which, in one operation, creates a file,
writes a byte to it and sets its uid, gid, last access time
and last modified time, but such an RPC would not be
reachable under a normal unix system.

In light of this limitation it is interesting to note that
Sun are proposing a new (postscript-based) network file
system protocol -- NeFS.
Postscript programs are written on the client, downloaded
to the server which then executes them returning results as desired.

Previous articles in this group have asked the question
"Who or what will write the postscript code?".
I believe that one proposed answer was along the lines of
"Not the applications programmer but the system programmer who
writes the kernel client code, and this will only need to be
written once for each operating system port.".
The idea implicit in this answer is that there will be some
simple mapping from each client system call to a corresponding
NeFS program template.
Other posters have pointed to the fact that RPC-based protocols
are seriously constrained by physical limits -- transcontinental
delays are of the order of milliseconds.
The NeFS approach is offered as a way around this problem.

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.

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.

I have long suspected with regard to NFS that Sun left behind some
of unix file system semantics so as to be able to support a wider
range of client and server platforms (e.g. PC's).  Now with the advent of
NeFS it seems that they may be moving further in this direction.

Perhaps some readers from Sun or elsewhere would like to comment?

Bruce Janson
Basser Department of Computer Science
University of Sydney
Sydney, N.S.W., 2006
AUSTRALIA

Internet:	bruce@basser.cs.su.oz.au
Telephone:	+61-2-692-3264
Fax:		+61-2-692-3838

.. now, back to PC-NFS.