NFS on System V

[Jim Reid]

In article <2438 at phri.UUCP> roy at phri.UUCP (Roy Smith) writes:
>In article <161 at wang7.UUCP> brezak at wang7.UUCP (John Brezak) asks about
>doing an NFS implementation in Xenix V without modifying the kernel.
>
>	It would be fairly easy (well, at least straight-forward) to do an
>NSF *server* in user code.  It may be counter-intuitive, but doing a client
>is actually harder than doing a server.  All a server has to do is respond
>to service requests on a synchronous basis.  A client has to be all over
>your program, getting involved every time you mention a path name.

The really hard part about the client side is figuring out how to get the
remote mounts done so the remote file pathnames look local. This more or
less has to go in the kernel somehow. You could put a layer of indirection
into the filesystem system calls, but this would slow everything up as the
new code would have to decide whether to do a local system call or perform
RPC to an NFS server for most I/O system calls.

>	I don't see any easy way to do an NFS server all in user code.  I
>suppose you could write a whole system call library which recognized when
>pathnames crossed NFS mount points (and symbolic links on 4.N systems), but
>it would be a real mess.  We're not just talking read and write here, but
>chdir and exec and mount as well.  Since you can execute binaries from
>remote file systems, things like demand paging have to go through NFS; I
>don't see any way to do that in user code.

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?

>	In fact, when you consider the mount system call, you have a
>situation where one process can effect another process that isn't even
>related to the first one by a common ancestor -- how are you going to keep
>that state information in user code and make it work right?

You don't. The NFS protocol means servers are stateless and they don't
really keep track of client mounts. (Details are kept in a file, but only
for information - the NFS code doesn't use it at all.) I understand the point
you're making, but it really boils down to the fact that the NFS code needs
to go in the kernel. A user-level service would be too kludgey to be
practicable.

		Jim

ARPA:	jim%cs.strath.ac.uk at ucl-cs.arpa, jim at cs.strath.ac.uk
UUCP:	jim at strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim
JANET:	jim at uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"