gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/07/87)
This NFS-vs.-RFS discussion reminds me of a question I wanted to ask: When we upgraded our Gould PowerNode 60x0/90x0 systems to UTX/32 Release 2.0, which incorporated NFS support, I was dismayed to discover that a perfectly ordinary program compiled in the BSD environment had died in the middle of what appears to be a large amount of Yellow-Pages support code dragged in from the C library. This was a total surprise to me, as the UNIX System V emulation that I provide doesn't include any of this stuff, nor will it! My question is, is this yp_* library crap really necessary for NFS? If so, the next question concerns how we go about stamping out NFS.
hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (01/09/87)
YP is conceptually separate from NFS. Pyramid supports NFS but not YP, because they aren't very happy with YP in its current form. However Gould is not alone in bundling the two together. Celerity seems to do so as well. In my view NFS is more general in its usefulness than YP. For a large set of diskless machines, it's very useful to have both. But NFS is also useful with larger timesharing system, an environment in which YP may not be necessary. There is nothing in NFS that makes it depend upon YP. They are both implemented on top of RPC, but they are separate services. When YP is present, programs are larger if they use any routine that reads from a YP database. Examples are the YP versions of standard C library routines for reading password entries, host table entries, etc.
jim@cs.strath.ac.uk (Jim Reid) (01/09/87)
In article <5488@brl-smoke.ARPA> Gwyn@BRL.ARPA writes: >This NFS-vs.-RFS discussion reminds me of a question I wanted to ask: > >When we upgraded our Gould PowerNode 60x0/90x0 systems to UTX/32 >Release 2.0, which incorporated NFS support, I was dismayed to >discover that a perfectly ordinary program compiled in the BSD >environment had died in the middle of what appears to be a large >amount of Yellow-Pages support code dragged in from the C library. >This was a total surprise to me, as the UNIX System V emulation >that I provide doesn't include any of this stuff, nor will it! > >My question is, is this yp_* library crap really necessary for NFS? No. Yellow Pages and NFS are independant of each other and you can use one without the other. You get Yellow Pages to "help" administer the local network - it just lets YP hosts keep track of changes to files like /etc/passwd, /etc/hosts and so on without having the system admin. update every copy of these files on each host every time they change. You can argue the case either way for having your SysV environment contain the YP code (and the underlying SUN XDR and RPC routines). However if it's possible that your SysV lookup routines will read files containing YP information, you should ensure the SysV code won't blow up if it gets YP entries instead of the usually expected data even if it won't make use of the YP routines. What scunnered (a good Scottish word!) me about YP was that it added about 18Kbytes - yes, 18Kbytes - to things like the password lookup routines. This was because getpwent() & friends now have to parse YP formats and perhaps make remote procedure calls, serialising and deserialising data using the XDR routines, as well as get conventional password entries. I could have taken the YP code out, but saving disk space is less important to me than wasting time editing umpteen password files. 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)!"
zorro@unixprt.UUCP (Commando Cody@unixprt) (01/11/87)
I understand that at UNIFORM/USENIX there will be a number of vendors tied together with NFS. Is there going to be a similar demonstration of RFS among different vendors? It seems to me that this is a very critical time for 5.3 RFS to demonstrate that it is a viable alternative to 4.2/3 SUN networking. There is enough momentum behind NFS that unless AT&T acts quickly, NFS will "win" by default and become the distributed unix standard.