brezak@wang7.UUCP (09/12/86)
Does any one have some information (ideas) on an implementation of Sun NFS on Xenix V ? The specifics are ideas on how to interface into the filesystem without modifying the kerenel. John Brezak 617/967-1839 uucp: ...!wanginst!wang!wang7!brezak
roy@phri.UUCP (Roy Smith) (09/16/86)
In article <161@wang7.UUCP> brezak@wang7.UUCP (John Brezak) asks about
doing an NFS implementation in Xenix V without modifying the kernel.
I asked essentially this same question at the NFS tutorial in
Atlanta. I don't know anything about Xenix V in particular, but I think
the answer is the same for any system. Some of this is based on the answer
I got at Atlanta, some of it is my own expounding on that.
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.
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.
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?
--
Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016jim@cs.strath.ac.uk (Jim Reid) (10/01/86)
In article <2438@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <161@wang7.UUCP> brezak@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@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
guy@sun.uucp (Guy Harris) (10/07/86)
> 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)
chris@umcp-cs.UUCP (Chris Torek) (10/08/86)
In article <278@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >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? The 4.2 file system came first, but not without looking ahead. NFS was perhaps the most pressing reason for the addition of mkdir() and rmdir(), though there are many other very good reasons for their existence. Actually, NFS *broke* a number of the additions, in rather subtle ways. Atomic renames are hard to do with component-at-a-time path resolution. Sun claims that this is a `feature'; I think it was a mistake. (The proper way to do name resolution, if you ask me, is to send the path components as counted strings, and have the returned result include a file handle and a residual component count.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jim@cs.strath.ac.uk (Jim Reid) (10/19/86)
In article <7961@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> 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. OK - I didn't make myself too clear in the original posting. The chronology is evident to anyone who looks as Guy said. However, I'm sure someone like Bill Joy had a network file system in mind when the design of the 4.2 filesystem was being thrashed out. We can all see when the two products were first shipped, but which design was outlined first? [There must have been some element of "if I have this system call, it'll make that network file system operation easier to do". (Note, I'm distingishing a "network file system" from NFS.)] >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. True, but I'd suggest that the initial design of both (whether consciously or not) went on in parallel. There are too many similarities for this to be just a happy coincidence. Jim ARPA: jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk UUCP: jim@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim JANET: jim@uk.ac.strath.cs "JANET domain ordering is swapped around so's there'd be some use for rev(1)!"
guy@sun.UUCP (10/23/86)
> We can all see when the two products were first shipped, but which > design was outlined first? "outlined" in what sense? Bill Joy was definitely "thinking ahead" when the 4.2 file system was designed, but since the 4.2BSD file system implementation was complete before NFS implementation even started, the fact that some idea that eventually ended up in NFS was first conceived before some other idea that eventually ended up in the 4.2BSD file system was is hardly interesting or relevant. > [There must have been some element of "if I have this system call, > it'll make that network file system operation easier to do". Why? Some element of "if I have this system call, it'll make some unspecified network file system easier to implement because you won't have to know how directories are put together on the other end" would have been sufficient. A grocery list of potential network file system operations is hardly a "design" for a network file system. > (Note, I'm distingishing a "network file system" from NFS.)] Something you should have done in the original posting if you wanted to make yourself clear. > True, but I'd suggest that the initial design of both (whether consciously > or not) went on in parallel. There are too many similarities for this to be > just a happy coincidence. Oh, good grief. You have people designing a network file system whose first implementation will be on a system with certain file system operations. It would be very surprising if the design of the network file system *didn't* show some influence from the "native" file system. Given that you have a "mkdir" system call, why should the implementors, say, give each of the microoperations in a "make directory" operation on a UNIX file system its own operation in the protocol, rather than putting in a "create directory" operation - especially given that future implementations of that network file system need not be on systems that have equivalents to those particular microoperations? Given that this network file system may be implemented on non-UNIX systems in the future, why should it define pathnames as being composed of 14-character-or-less file names? Given that the operating system that it is to be first implemented on supports symbolic links, and given that there is no *requirement* that an NFS server implement them (presumably you just get some error return back if you try to make a symbolic link on a file system that doesn't support them), why should the protocol not support symbolic links? The similarities in question merely suggest that there was a flow of influence in *one* direction; a bi-directional flow would be unnecessary, and should not be assumed in the absence of evidence that cannot be explained otherwise. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
brett@wjvax.UUCP (Brett Galloway) (10/24/86)
In article <292@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >OK - I didn't make myself too clear in the original posting. The chronology >is evident to anyone who looks as Guy said. However, I'm sure someone like Bill >Joy had a network file system in mind when the design of the 4.2 filesystem >was being thrashed out. We can all see when the two products were first >shipped, but which design was outlined first? [There must have been some >element of "if I have this system call, it'll make that network file system >operation easier to do". (Note, I'm distingishing a "network file system" >from NFS.)] > [more about NFS "slotting into" 4.2BSD >True, but I'd suggest that the initial design of both (whether consciously >or not) went on in parallel. There are too many similarities for this to be >just a happy coincidence. In fact, in the document, "A Fast File System for UNIX", by M. McKusick, W. (Bill) Joy, S. Leffler, and R. Fabry, section 5.3 (symbolic links) says In future Berkeley software distributions it will be possible to mount file systems from other machines within a local file system. When this occurs, it will be possible to create symbolic links that span machines. -- ------------- Brett Galloway {pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
guy@sun.uucp (Guy Harris) (10/26/86)
> In fact, in the document, "A Fast File System for UNIX", by M. McKusick, > W. (Bill) Joy, S. Leffler, and R. Fabry, section 5.3 (symbolic links) says > > In future Berkeley software distributions it will be possible to > mount file systems from other machines within a local file > system. When this occurs, it will be possible to create > symbolic links that span machines. Unfortunately for these Ancient Astronauts-style theories about the 4.2BSD file system and NFS, the future networked file system being referred to there was NOT NFS. First of all, I don't think a real design existed; it was a wishlist item than a real future idea. Second of all, what ideas did exist may have latter appeared in NFS, but not without much change later. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)