benoy@apollo.uucp (Benoy Desouza) (06/07/88)
(I'm speaking on a personal basis and not as a representative of Apollo)
Is Apollo's NFS implementation a "true" NFS or not ? It certainly is !
To quote from a letter we received from Sun just before we released NFS.
"This is to confirm that Sun Microsystems has tested the Apollo
implementation of the Sun Network File System protocols, as agreed
in our trademark license agreement. We found that the Apollo implementation
performed comparably with other NFS implementations previously tested by Sun.
Sun hereby approves shipment by Apollo of the tested implementation".
Thus our NFS is in complete compliance with Sun's certification
procedures. Hence Apollo's NFS is able to communicate with ALL other
compliant NFSs.
Our NFS has several advantages from its close ties to the
Domain/OS operating system. For example:
- users at foreign systems (wrt Apollo) can mount the Apollo network
root directory (//) to gain access to file systems anywhere on a
Domain network.
- users at Apollo workstations can mount foreign file systems in the
Apollo network root directory. This enables users throughout an Apollo
network to use the same names when accessing those file systems. Thus
one does not have to mount the foreign system on every node that
wants to access it.
Benoy De Souza
Apollo Computers Inc.crgabb@sdrc.UUCP (Rob Gabbard) (06/07/88)
In article <3c80c931.4653@apollo.uucp>, benoy@apollo.uucp (Benoy Desouza) writes: > (I'm speaking on a personal basis and not as a representative of Apollo) > > Is Apollo's NFS implementation a "true" NFS or not ? It certainly is ! > To quote from a letter we received from Sun just before we released NFS. > Apollo's implementation is a true one but useful only for ascii-based i/o activities (copying, editing, etc.) Unlike every other NFS implementation I've seen, Apollo's compilers can not write to an NFS disk and you can not execute binaries that reside on an NFS disk because of the file typing issues. I feel DOMAIN is a much better remote file system implementation than NFS but it's not very heterogeneous. Apollo needs to address this NFS problem. Once they get past this obstacle - how about a Yellow Pages implementation to replace the registry ? Once again, I like the registry better than Yellow Pages but it's not very -- well, you know. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rob Gabbard | UUNET: uunet!sdrc!crgabb Workstation Systems Programmer | PHONE: (513)576-2600 Structural Dynamics Research Corporation | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/10/88)
Actually, Apollos NFS implementation can be used for any activity which does its I/O through the streams (IOS) facility. You can read or write unformatted Fortran data files via NFS (which a REC type files on the Apollo). You can execute programs via NFS because the loader bypasses the streams manager (which is where the NFS mount point is handled by the type manager) and maps the executable file directly into memory. The problem lies not in NFS, but in the loader. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/10/88)
We use a beta-test copy (yup, still have not gotten around to shelling out real bucks) of NFS to read and write files between our Apollos and 1) a Sun 3/160 reading/writing a tar tape 2) an Alliant FX/1 running Fortran programs 3) an Alliant FX/40 running Fortran programs 4) the same Sun 3/160 editing files 5) a PC/XT clone running a CD-ROM reader (has not been used for some time). Since Sun created NFS, I'd say that being able to work with a Sun is the definition of a working NFS implementation. Many of the other 'implementations' of NFS are simply licensed copies of Sun's source code that have been plugged into the vendor's version of BSD4.2. If Apollo NFS works with Sun and (for example only) Pyramid NFS works with Sun and Apollo NFS does *not* work with Pyramid NFS, whose problem is it? Apollos? Pyramid's? Who can say? Maybe it's Sun's problem for not having a validation suite which is tight enough? God knows that TCP/IP has been out long enough for vendors to have presumably gotten the hang of it, and yet we've still had ethernets brought to their knees by /etc/routed implementations that didn't do so well in the MIT Internet environment. There is a very old dilema for computer managers. That is the decision whether to buy all of your equipment from the same vendor, or to save some (potentially very large) bucks by buying your peripherals directly from the distributor. The trade off is between saving money, and the endless finger pointing that occurs when something isn't working. Vendor independent networking has this endless finger pointing even when it is business as usual. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (06/10/88)
In article <292@sdrc.UUCP>, crgabb@sdrc.UUCP (Rob Gabbard) writes: > > I feel DOMAIN is a much better remote file system implementation than NFS > but it's not very heterogeneous. Apollo needs to address this NFS problem. > Once they get past this obstacle - how about a Yellow Pages implementation to > replace the registry ? Once again, I like the registry better than Yellow Pages > but it's not very -- well, you know. > Rob, I agree with you - I feel the Apollo solution in a number of areas is superior. Since we agree, just how important is being all the same, versus being better? I for one prefer the Apollo extensions that permit preservation of file timestamps, for example, and feel the drive to a standard that offers less results in less. I'd vote to extend and expand DOMAIN and forget X, but I just have to get my job running, not sell workstations... -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------
heinzl_c@apollo.UUCP (Carl Heinzl - Apollo Computer, Chelmsford, MA) (06/11/88)
In an earlier article Rob Gabbard states: > Apollo's implementation is a true one but useful only for >ascii-based i/o activities (copying, editing, etc.) Unlike every other >NFS implementation I've seen, Apollo's compilers can not write to an NFS >disk and you can not execute binaries that reside on an NFS disk because of >the file typing issues. The reason that you cannot execute binaries on an NFS partition is that the loader maps the binary into the address space of the process and these os calls can not be executed on files that live across nfs partitions, after all a remote file system will (unless it's an Apollo) have no knowledge of ms_$ calls. And, if you have several Apollo's, then there's no reason to not have them joined by a DOMAIN ring with appropraite gateways into the rest of your environment. You can certainly copy the file, execute it and delete it afterwards, after all a standard loader reads the executable (just like a copy would) and runs it from there. Don't forget exactly what we're discussing here either. Do you actually want to try and run a binary on an Apollo that lives on a SUN, sorry - it just won't work. Try running a VAX binary on your SUN and see what results you get there. > > I feel DOMAIN is a much better remote file system implementation than NFS >but it's not very heterogeneous. Apollo needs to address this NFS problem. Now then, in light of the discussion above, exactly what *NFS* problem are you talking about? My feeling is that the NFS at Apollo is a VERY good implementation, now perhaps other groups at Apollo need to work at making things work better in a heterogeneous environment. Carl Heinzl WA3UEN --- heinzl_c@apollo.UUCP (617) 256-6600 x7153
aad@stpstn.UUCP (Anthony A. Datri) (06/12/88)
> theoretically since it is a fully functional NFS this should be > possible..right? Whoa! The pcnfs stuff I've seen from Sun seems to regard pcnfs as a separate but related system, not a part of nfs (sorta like tftp/ftp). You don't always get pcnfs with nfs -- different daemons. Now, I have no great personal love of Apollo's NFS -- we had a couple of apollo guys out for a couple days to make ours work. As it is, the apollo routed'ss seem to be doing very strange things, and I've got one diskless machine (nodes are for linked lists) who, when I switched its partner (a harrowing ordeal in and of itself), decided to go bonkers with tcp. I now have to manuall kill the tcp_server, inetd, and routed's on it after it boots, then restart them. Then they work. The inetd starts up without the info in /etc/networks, and ...and... ARRRRRRRGGGHGHHGGGGHHHH! We should all go back to 11/45's running berknet. (you think I'm kidding!) -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
guy@gorodish.Sun.COM (Guy Harris) (06/14/88)
> Whoa! The pcnfs stuff I've seen from Sun seems to regard pcnfs as > a separate but related system, not a part of nfs (sorta like tftp/ftp). > You don't always get pcnfs with nfs -- different daemons. PC-NFS uses NFS as the file access protocol. I believe there is a "pcnfs daemon" that handles PC-style file locking or something like that. Not like TFTP/FTP at all; more like NFS and the (acronymless, as far as I know) network locking protocol.
geoff@eagle_snax.UUCP ( R.H. coast near the top) (06/14/88)
In article <1825@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: > > theoretically since it is a fully functional NFS this should be > > possible..right? > > Whoa! The pcnfs stuff I've seen from Sun seems to regard pcnfs as > a separate but related system, not a part of nfs (sorta like tftp/ftp). > You don't always get pcnfs with nfs -- different daemons. [Wot? A Sun person posting to comp.sys.apollo?! Oh, well...] This is a very misleading characterization of PC-NFS. PC-NFS is a complete client-only implementation of the NFS protocols, and will interoperate with any correct NFS server implementation "as is", with no additional daemons. To improve the usability of the PC-NFS product we supply an additional daemon which provides network authentication and print services, but this is not required for correct NFS operation. (You can think of PCNFSD as an alternative to "lpd" plus an authentication daemon, rolled into one.) It's correct that you don't "get" pcnfs with nfs. It's a product which we sell, just like many NFS vendors sell their NFS implementations. Others bundle NFS into the base OS. It's a marketing choice which has nothing to do with protocols, interoperability, or daemons.... -- Geoff Arnold, Sun Microsystems | "We didn't set out to kill anyone" TOPS at ECD (home of PC-NFS) | [Reagan on the Libyan air raid, included UUCP:{ihnp4,decwrl...}!sun!garnold | in "Quotations of Chairman Ron" along ARPA:garnold@sun.com | with other insightful observations.]
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (06/18/88)
In article <3c9567ba.d858@apollo.uucp> heinzl_c@apollo.UUCP (Carl Heinzl - Apollo Computer, Chelmsford, MA) writes: | Do you actually want to try and run a binary on an Apollo that |lives on a SUN, sorry - it just won't work. Try running a VAX binary on your |SUN and see what results you get there. Sorry for the flame but your statement shows real ignorance. I can't believe you said it. You are missing the point/advantage of NFS. Try running a Vax binary STORED on a sun ON a VAX. This works fine. Or run a Sun binary on a Sun that is on a Vax NFS server. It doesn't matter what type of architecture the NFS server is. The semantics are the same. We have an NFS server that is cheaper and faster than a Sun or VAX. It has more disk space and mutliple ethernet controllers so it can connect to several different segments. Great place for home directories. We can log onto a VAX, Sun, Encore, Convex, Alliant and perhaps HP or Tektronix, and have the same/single home directory. If we include $HOME/bin/`arch` in our search path, we can have binaries for EACH architecture in our SINGLE home directory. Except Apollo. It seems that only Apollo NFS servers can be transparently used for Apollo machines, while all of the other implementations (that I am aware of) can provide 'heterogeniality'. :-) -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett
crgabb@sdrc.UUCP (Rob Gabbard) (06/21/88)
In article <3c9567ba.d858@apollo.uucp>, heinzl_c@apollo.UUCP (Carl Heinzl - Apollo Computer, Chelmsford, MA) writes: > would) and runs it from there. Don't forget exactly what we're discussing > here either. Do you actually want to try and run a binary on an Apollo that > lives on a SUN, sorry - it just won't work. Try running a VAX binary on your > SUN and see what results you get there. > > > > > I feel DOMAIN is a much better remote file system implementation than NFS > >but it's not very heterogeneous. Apollo needs to address this NFS problem. > > Now then, in light of the discussion above, exactly what *NFS* problem are you > talking about? I simply want to store Apollo executables on an NFS-mounted disk and have an Apollo execute them from that disk just as if they were on a local disk or on a disk accessed via DOMAIN. For example, if disk space is low on the Apollo ring, I have nowhere to turn. If disk space is low on the Suns or HPs or any other NFS-running UNIX box I can turn to another NFS-server machine, including VAX/VMS and use some space there. Sure, I can store non-executables there, but why restrict the users in such a way ? It should be transparent to them. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rob Gabbard | UUNET: uunet!sdrc!crgabb Workstation Systems Programmer | PHONE: (513)576-2600 Structural Dynamics Research Corporation | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/21/88)
Actually, Apollo NFS servers can handle binaries for any machine
*except* an Apollo. As has been previously stated, the problem is
with the Apollo loader and the compilers. They bypass the stream I/O
system (and therefore NFS) for the objet files. The compilers do use
the stream I/O system for the sources, which is why the source files
can be stored on an NFS server. Stop beating on Apollo's NFS
implementation -- it's not the problem! The loader/compilers are
the problem! They presumably bypass the IOS managers for performance
reasons, but it would not be that hard for them to test if the
object file was on an NFS file system and to switch over to
using IOS calls if that was the case.
-- David Krowitz
krowitz@richter.mit.edu (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)
P.S. For that matter, WBAK/RBAK have the same problem -- you can't
backup NFS file systems unless you use 'tar' which is not
(in my opinion) quite as flexible, but which does use the
IOS system.benoni@ssc-vax.UUCP (Charles L Ditzel) (06/22/88)
in article <4646@vdsvax.steinmetz.ge.com>, barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) says: | In article <3c9567ba.d858@apollo.uucp> heinzl_c@apollo.UUCP | (Carl Heinzl - Apollo Computer, Chelmsford, MA) writes: | | Do you actually want to try and run a binary on an Apollo that | |lives on a SUN, sorry - it just won't work. Try running a VAX binary on your | |SUN and see what results you get there. | Sorry for the flame but your statement shows real ignorance. | I can't believe you said it. | You are missing the point/advantage of NFS. | Try running a Vax binary STORED on a sun ON a VAX. This works fine. | Or run a Sun binary on a Sun that is on a Vax NFS server. | It doesn't matter what type of architecture the NFS server is. | The semantics are the same. Thank you Bruce I couldn't have said it better. Since my initial posting I have seen a demo of Apollo NFS and it seems like there is a glimmer of hope. As to the question about WHY one would want to run NFS between two Apollos - Say you have two seperate domain rings with ethernet connecting them and a multitude of other machines... suddenly NFS between Apollo and executing files on the remote machines seems not only plausible but extremely useful...I know of occurances where NFS machines talking over Ethernet were 50 miles away...(they were Suns and in another case they were Silicon Graphics)...being able to connect Apollos and execute programs on the remote machines (via NFS) would be useful for testing, etc. Thanks y'all for all the replies...alot of the information has been very helpful.
rees@A.CC.UMICH.EDU (Jim Rees) (06/28/88)
I simply want to store Apollo executables on an NFS-mounted disk and have an
Apollo execute them from that disk just as if they were on a local disk or on a
disk accessed via DOMAIN.
The NFS client code is implemented on the Apollo side as an extensible
streams type manager (see my Atlanta Usenix paper). This means anything
that goes through the I/O system (open, close, read, write) can use NFS.
But programs aren't loaded through the I/O system. They are loaded
through mapped files, which is at a lower layer (I/O to normal disk
files is done by mapping them).
The fix for this is obvious but not trivial to implement. What's needed
(in my opinion) is an "exec" trait, whose operations would be things
like "load text into memory." The domain disk file manager would do this
the way it always has, by directly mapping the file and paging out of it.
The NFS manager would have to copy the text and initialized data into
a temp file, which is a little yucky (you wouldn't get demand paging)
but would work.
To get demand paging, you would have to layer the paging system on top
of NFS, instead of the other way around as it is now. This would not
be easy since you'd also have to re-layer TCP (ok, IP/UDP).
The fact that the compiler won't deliver code into an NFS receptacle
is just a plain, ordinary bug, one that I hope gets fixed sometime
soon (maybe I should learn how to file a UCR?)
I know that this explanation doesn't help solve your problem, but I
thought some of you might be interested anyway.
-------chinn@apciseaapcisea.UUCP (3C3AF053.B0012B28) (06/29/88)
In article <2027@ssc-vax.UUCP>, benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > Since my initial posting I have seen a demo of Apollo NFS and it seems like You mean you've been flaming us all this time and you hadn't even seen the product yet !!! :-). > there is a glimmer of hope. As to the question about WHY one would want > to run NFS between two Apollos - > Say you have two seperate domain rings with ethernet > connecting them and a multitude of other machines... you mean like they have in chelmsford; where the corporate net has in excess of 2000 nodes hooked together. Where the primarily manufacturing nets (rings ethers, etc) are ether'd to all the other nets for R&D, marketing, sales, and whatever else (which are also rings, ethers, etc) back in Massachusetts. > remote machines seems not only plausible but extremely > useful...I know of occurances where NFS machines talking useful is a relative term. Certainly you can get the NFS functionality required, (if you want), but most people want to use things like the single name space, display manager capabilities and etc, even on the nodes which are physically far away from each other. This can, of course be done using internets. And please don't tell me you don't like it cause it is different; how many products have you ever developed in which you made absolutely no design decisions to tradeoff commonality for functionality? And ether bridge is something like 3 commands and no configuration files to edit. (One could argue that it is easier than setting up NFS on a Sun.) And the product does not exclude using NFS between your suns and vaxen that you have connected to your ether. Or between your xyz machines and apollos on a ring, ether, t1 or etc. On the subject of mapping files; perhaps the compilers/loaders could be modified to recognize when to map, and when to handle the object as a byte stream; I'm not sure and am in the process of asking someone. However, to say that apollo is the only company that has this particular problem is patently untrue; it turns out that there are a few of computer manufacturers that map files into the address space (why? because it's a good idea! check out mach from cmu), and it turns out that they have the same NFS worries. ...uw-beaver david m. chinn !apcisea apollo computer inc !chinn bellevue sales office (206) 453-5544 bellevue, washington ================================================================================ Opinions? Me, have opinions?!? The preceding was a figment of a very active imagination, and I can't imagine my company sharing any of my figs ================================================================================
guy@gorodish.Sun.COM (Guy Harris) (06/30/88)
> it turns out that there are a few of computer manufacturers that map files > into the address space (why? because it's a good idea! check out mach from > cmu), and it turns out that they have the same NFS worries. Not all of them; I know of one, a workstation manufacturer in Mountain View named "Sun Microsystems", that maps files into the address space but does not have the same NFS worries. As was noted earlier, it's a question of how your system is layered; if your paging system can't be put atop NFS, it obviously makes mapping files into your address space over NFS more difficult.
chinn@apciseaapcisea.UUCP (3C3AF053.B0012B28) (06/30/88)
yesterday, in my somewhat wild eye enthusiasm, my fingers made a slight slip: >excess of 2000 nodes hooked together. Where the primarily manufacturing nets >(rings ethers, etc) are ether'd to all the other nets for R&D, marketing, sales, ^^^^^ The networks in question are in Exeter, NH and Chelmsford, MA; they are t1'd together, not ether'd this was not intended to mislead anyone; sorry if it had. ...uw-beaver david m. chinn !apcisea apollo computer inc !chinn bellevue sales office (206) 453-5544 bellevue, washington
benoni@ssc-vax.UUCP (Charles L Ditzel) (07/01/88)
in article <155@apcisea.UUCP>, chinn@apciseaapcisea.UUCP (3C3AF053.B0012B28) says: > > In article <2027@ssc-vax.UUCP>, benoni@ssc-vax.UUCP (Charles L Ditzel) writes: > >> Since my initial posting I have seen a demo of Apollo NFS and it seems like > > You mean you've been flaming us all this time and you hadn't even seen the > product yet !!! :-). As I clearly stated I was looking to get the product for an eventual network that involved an SGI machine and some PCs. I had looked at some fairly complete benchmarks of Apollo NFS, plus I had been asking LOTS of questions prior to my posting. As I mentioned some of the people were telling me that Apollo to Apollo binaries over NFS would not execute...(i was confirming this unfortunate state of affairs in Apollo-land)...so given that discouraging bit of information...I didn't have very high hopes for it working with the SGI or PCs...(thus enter my inquiry)... By the way does not owning the product change the fact that it doesn't execute Apollo executables? or that it is dramatically slower than other versions of NFS? or should I foolishly go out and naively buy it only to find out and skip what I've learned from many others? > useful is a relative term. Certainly you can get the NFS functionality > required, (if you want), but most people want to use things like the single > name space, display manager capabilities and etc, even on the nodes which are > physically far away from each other. My interest is for machine x to use machine y's disk, printers, etc. I am not that interested in the display managers capabilities as a priority. > This can, of course be done using internets. And please don't tell me > you don't like it cause it is different; how many products have you ever > developed in which you made absolutely no design decisions to tradeoff > commonality for functionality? And ether bridge is something like 3 > commands and no configuration files to edit. > (One could argue that it is easier than setting up NFS on a Sun.) Seeing as I just set NFS on a Sun up, I assume it must be very easy. Again NFS provides a transparent cover which we intend to use with PCs, Macs, SGIs and other machines...if Ether Bridge fits that (I know nothing about Ether Bridge) then I am open-minded about the situation....if it doesn't provide the same tranparent behavior then....i'm not....i certainly will look into it... > apollo is the only company that has this particular problem is > patently untrue; it turns out You are correct in stating that Apollo is not unique to this problem. As I have discovered from digging deeper. However, given the number of machines that work with NFS it might be in a companies interest to fix it. ------- My opinions are naturally my own.