Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!pyramid!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: NFS on System V Message-ID: <7961@sun.uucp> Date: Tue, 7-Oct-86 01:52:20 EDT Article-I.D.: sun.7961 Posted: Tue Oct 7 01:52:20 1986 Date-Received: Wed, 8-Oct-86 00:42:16 EDT References: <161@wang7.UUCP> <2438@phri.UUCP> <278@stracs.cs.strath.ac.uk> Distribution: net Organization: Sun Microsystems, Inc. Lines: 62 > 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@sun.com (or guy@sun.arpa)