paf@unixprt.UUCP (Paul Fronberg) (03/29/88)
Another point in the on going RFS-NFS wars: NFS seems to be coupled with TCP/IP. I have not seen anyone running it with other protocols whereas I have seen RFS running with several different TLI providers. Currently this shouldn't make any difference right now since most everyone has BSD 4.* TCP/IP in one form or another. It'll be interesting to see what happens when ISO, X.25 become important.
ehrlich@blitz (Dan Ehrlich) (03/30/88)
In article <303@unixprt.UUCP> paf@unixprt.UUCP (Paul Fronberg) writes: >Another point in the on going RFS-NFS wars: >NFS seems to be coupled with TCP/IP. I have not seen anyone running >it with other protocols whereas I have seen RFS running with >several different TLI providers. While I do not claim any vast expertise in NFS, from looking at the specifications for NFS and RPC there is really nothing that couples NFS or RPC to TCP/IP. It just happens to be the first transport protocol that NFS was implemented on. Any protocol suite that comes close to the ISO model should be a resonable transport method. > >Currently this shouldn't make any difference right now since most everyone >has BSD 4.* TCP/IP in one form or another. It'll be interesting to see >what happens when ISO, X.25 become important. If SUN has there act together this is probably already running in house. Dan Ehrlich <ehrlich@blitz.{cs.psu.edu,bitnet,uucp}> The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723 Dan Ehrlich <ehrlich@psuvax1.{cs.psu.edu,bitnet,uucp}> The Pennsylvania State University, Department of Computer Science 333 Whitmore Laboratory, University Park, PA 16802 +1 814 863 1142 or +1 814 865 9723
schwartz@gondor.cs.psu.edu (Scott Schwartz) (03/31/88)
In article <303@unixprt.UUCP> paf@unixprt.UUCP (Paul Fronberg) writes: >Another point in the on going RFS-NFS wars: >NFS seems to be coupled with TCP/IP. I have not seen anyone running >it with other protocols whereas I have seen RFS running with >several different TLI providers. RPC runs on whatever you want it to, and NFS runs on RPC, the particular network protocol shouldn't be that big an issue. I have heard that there is a faction within Sun that thinks NFS should run on TCP, but for the present: gondor% egrep "TCP|UDP" /usr/src/new/sunrpc3.9/doc/nfs.rfc.ms NFS currently is supported on UDP/IP only. The NFS protocol currently uses the UDP port number 2049. This is The mount service is currently supported on UDP/IP only. gondor% Quote of the week: in unix review, Bill Joy says that NFS is the "rotary dial" of network filesystems, and that something better will invariably come along. -- Scott Schwartz | Your array may be without head or schwartz@gondor.cs.psu.edu | tail, yet it will be proof against | defeat. -- Sun Tzu, "The Art of War"
dave@spool.cs.wisc.edu (Dave Cohrs) (03/31/88)
In article <303@unixprt.UUCP> paf@unixprt.UUCP (Paul Fronberg) writes: >Another point in the on going RFS-NFS wars: >NFS seems to be coupled with TCP/IP. A nitpic: NFS, as used on most machines, uses UDP/IP. TCP is too slow and is stateful. I'm know there are other NFS implementations (Lachman did/is doing one over ISDN). Nothing in NFS itself assumes that it uses UDP. The biggest problem I would see with using a X.25 is that X.25 is stateful, which would probably make NFS slower. dave Dave Cohrs +1 608 262-6617 UW-Madison Computer Sciences Department dave@cs.wisc.edu ...!{harvard,ihnp4,rutgers,ucbvax}!uwvax!dave
sas@pyrps5 (Scott Schoenthal) (03/31/88)
In article <5491@spool.cs.wisc.edu> dave@spool.cs.wisc.edu (Dave Cohrs) writes: >A nitpic: NFS, as used on most machines, uses UDP/IP. TCP is too slow >and is stateful. I'm know there are other NFS implementations (Lachman >did/is doing one over ISDN). Nothing in NFS itself assumes that it >uses UDP. The biggest problem I would see with using a X.25 is that >X.25 is stateful, which would probably make NFS slower. Please don't confuse the "statelessness" of the NFS server implementation with the class (sp., connection-oriented, connectionless) of the underlying transport. Opinion: Using NFS over an unreliable link (e.g, not a friendly Ethernet/802.3 LAN) would probably require some lower-level connection-oriented service. Sun's NFS/RPC, in its kernel implementation, is geared toward a "reliable" unreliable transport. That is, while UDP/IP is connectionless, the Ethernet is a moderately reliable physical link and, disregarding overruns, etc., at the server (or gateways, bridges), most packets will get through. On the other hand, NFS/RPC performance degrades significantly when the link becomes lossy. The problem with X.25 is not that it is stateful, just that it is slow(er). Grabbing a 4Kbyte block from a remote system is a mighty big difference when performed over a 56kb line versus over an Ethernet at essentially Mbit rate. In addition, adjusting NFS call timeouts is an art: most people I've talked to pick an arbitrary value and then tinker with it until it seems right. In the current implementation of kernel RPC, there is no "smoothing" function which could adjust the timeouts based upon previous experience calling to a particular host. sas ---- Scott Schoenthal sas@pyrps5.pyramid.com Pyramid Technology Corp.
guy@gorodish.Sun.COM (Guy Harris) (04/01/88)
> >NFS seems to be coupled with TCP/IP. I have not seen anyone running > >it with other protocols whereas I have seen RFS running with > >several different TLI providers. > > RPC runs on whatever you want it to, and NFS runs on RPC, > the particular network protocol shouldn't be that big an issue. Correct. I don't know what transport protocols RFS was run atop; many of them (various Starlan protocols and NPACK) can probably be classified as "uninteresting" as they are non-standard protocols. > I have heard that there is a faction within Sun that thinks NFS > should run on TCP... I know of no such faction, but that means nothing. It could be run atop TCP in conventional UNIX systems were a kernel TCP transport to be created for it. It *has* been run as a "proof-of-concept" demo atop the ISO connectionless network protocol. At some point, Sun RPC, and thus NFS, will probably run atop the ISO connectionless transport protocol; RPC would also probably run atop TP4. It could presumably be run atop the XNS Packet Exchange Protocol; given that Xerox plans to do something with SPARC processors running UNIX, this may eventually happen.
bae@ati.tis.llnl.gov (Hwa Jin Bae) (04/01/88)
There's been good discussions regarding the protocol independence
of NFS design, however let me start a new discussion on
possible new NFS implementation strategies.
Since I haven't had the pleasure of reading SUN's NFS implementation
source codes, I have a few questions regarding possible implementation
of a NFS system as a user process. The RFC pretty much does a
good job of describing the NFS protocols but it is not explicitly
indicated how you would go about implementing the client side exactly -
I guess it will have to be implemented as modifications to kernel much
like the RFS (public domain implementation of a remote file system, not
to be confused by the better known RFS - remote file sharing - by AT&T),
which doesn't use the mount points like NFS but uses a file that gets
used by namei() routine in the kernel to distinguish remote filesystems
from local filesystems. The server side would be relatively easy to
implement as a user level process by just following the protocol specification
(of which a good rpcgen input file exists with latest RPC package from SUN)
and implementing various services. Does anyone have a good idea as to
how one would go about implementing the client as a user level process and
still meet the same NFS specifications on a UNIX system? The reason
for trying to implement everything is for portability. In particular,
I am interested in knowing how PC-NFS (client only, right?) is implemented.
Is it implemented as a modification to the MS-DOS kernel?
I'm very curious...
Hwa Jin Bae | I only work for LLNL and CDC; they are not responsible
Control Data Corp. | for my personal opinions.
4234 Hacienda Drive | bae@{ati,aftac,vega}.tis.llnl.gov (Internet)
Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae (UUCP)rwhite@nusdhub.UUCP (Robert C. White Jr.) (04/02/88)
in article <3401@psuvax1.psu.edu>, ehrlich@blitz (Dan Ehrlich) says: >>Currently this shouldn't make any difference right now since most everyone >>has BSD 4.* TCP/IP in one form or another. It'll be interesting to see >>what happens when ISO, X.25 become important. > > If SUN has there act together this is probably already running in house. NFS is not bound to the transport provider's protocol at all. also NFS and RFS are going to be "co resedent" protocols in a few months. That is one of the big things both partys were going for in the SUN/ AT&T get together. The tow systems will come toghether, and the SA will select which one is "primary" on site, but both protocols will be available on any media which supports either. Rob. [p.s. Treat this article as a rumor... copy liberally then destroy the original]
KWALDMAN@wash-vax.bbn.com (11/16/88)
I have a problem with using NFS. My hardware setup is a MASSCOMP 5600, a SUN 4/110 and a SUN 3/160. From the Masscomp I can cross mount both suns disks, from the Sun 3/160 I can cross mount both the Sun 4/110 and the Masscomps disks. However, from the Sun 4/110 I can only cross mount the Sun 3/160's disk. When I try the Masscomp disks it gives me an access denied error. Any one know why? The hosts.equiv files are all the same " + " and the exports have the exportable directories and hostnames in them in the proper format. Thanks Karl
schwartz@shire.cs.psu.edu (Scott Schwartz) (03/27/89)
In article <Mar.26.19.51.41.1989.8372@geneva.rutgers.edu>, hedrick@geneva (Charles Hedrick) writes: >You'll see that foo has been renamed to .nfsXXX. Now if you kill the >tail, .nfsXXX will go away. I'm not sure quite how that interacts >with statelessness. It's possible that if you open a file, remove it, >and then crash before closing it, that the .nfsXXX file will stay on >the the file server. I haven't looked at the code that carefully. From crontab: find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune >Despite all the comments about how NFS violates "Unix semantics", >we've not run into anything that failed across NFS, aside from bugs in >implementations. That's because of hacks like the above :-) NFS is stateless, except for the state it maintains (on disk). -- Scott Schwartz <schwartz@shire.cs.psu.edu>