NFS on System V

[Guy Harris]

> I agree a user level NFS server would be ugly, but not quite as nasty as you
> suggest. The real trouble with NFS on non 4.[23] based systems are to do
> with the Berkeley additions that just slot into the NFS protocol - atomic
> rename, mkdir system call, symbolic links, long filenames and so on. It's
> curious how some of these additions make implementing NFS easier. I wonder
> which came first - the new 4.2 filesystem or the Network File System?

I have no idea why anybody would wonder that; 4.2BSD came out sometime in
1983 (and the 4.2 file system first appeared in 4.1bBSD, which predated
4.2BSD), while NFS was first shipped sometime in 1985.  Both these dates can
be deduced with just a little research, so I see little to speculate on here.

For further ammunition, we check the paper "A Fast File System for UNIX", in
the 4.2BSD documentation.  It says:

	The preliminary design was done by Bill Joy in late 1980; he
	presented the design at the USENIX conference held in San
	Francisco in January 1981.  The implementation of the design
	was done by Kirk McKusick in the summer of 1981.  Most of the
	new system calls were implemented by Sam Leffler.  The code
	for enforcing quotas was implemented by Robert Elz at the
	University of Melbourne.

(For those of you with an incurable speculative bent, the creation date
recorded in the SCCS file for all of the NFS source files in the Sun kernel
is July 27, 1984.)

The reason why things like "mkdir" and "rename" make implementing NFS easier
isn't curious in the least; one of the reasons for the directory library,
and the reason for calls like "mkdir" and "rmdir", was to make directories
into objects the details of whose implementation are private to the kernel,
so that other file system types can be plugged into a UNIX system without
changes to applications.

This, of course, includes network file systems - 1) because they represent a
new file system type (at least in the Sun implementation) and 2) because, if
a server is implemented on a different operating system than the client, you
have in a sense plugged the file system type on the server into the client.

None of these cause real problems for server implementations.  You can put
code to create directories and establish the "."  and ".."  links into a
non-4.2BSD kernel, and have the NFS server use that code.  (Having done so,
of course, you might as well make this code available to user programs as
well, using a "mkdir" system call.)  The same applies to "rmdir" and to
directory-reading code.

Once you've done all this, you can more easily implement the client side as
well, since you have (as suggested in the previous paragraph) implemented
"mkdir" and "rmdir".  Yes, you then have to change applications to use
"mkdir", "rmdir", and the directory library.  AT&T-IS did the same thing for
RFS.  (Note, BTW, that there are bugs in the System V Release 2 "make" and
"sh" that are fixed simply by rewriting them to use the directory library,
since the directory library guarantees that the file name in the directory
entries it returns pointers to are null-terminated.)

Saying the Berkeley additions "just slot into the NFS protocol" is
misleading; one could equally well say the NFS protocol was influenced by
the operations supported by the 4.2BSD file system.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)