gavin@mit-caf.MIT.EDU (Gavin C. H. Zau) (07/12/89)
We have PC-NFS running on 286s connecting them to a MIPS M120 functioning as an NFS server. Now we are considering purchasing some Mac IIs for graphical work. Is NFS avaliable on the Mac IIs? If so what hardware do I need? If not is there an alternative that would work? thanks. -- Gavin Zau Dept of Chemical Engineering, MIT gavin@caf.mit.edu mefl@eagle.mit.edu
sharon@asylum.SF.CA.US (Sharon Fisher) (07/12/89)
In article <2596@mit-caf.MIT.EDU> gavin@mit-caf.UUCP (Gavin C. H. Zau) writes: > > We have PC-NFS running on 286s connecting them to a >MIPS M120 functioning as an NFS server. Now we are considering >purchasing some Mac IIs for graphical work. Is NFS avaliable on >the Mac IIs? If so what hardware do I need? If not is there >an alternative that would work? My understanding of the situation is this: there is one NFS implementation for the Mac, done by the CITI folks, but it was done under contract to Apple and so can't be distributed. Apple was going to announce an NFS product on June 12 but pulled it a few weeks before that for some unspecified reason. -- "Inanna spoke: My vulva, the horn, the Boat of Heaven, is full of eagerness like the young moon. My untilled land lies fallow. As for me, Inanna, who will plow my vulva? Who will plow my high field? Who will plow my wet ground?" Inanna: Queen of Heaven and Earth Her Stories and Hymns from Sumer
goodloe@b11.ingr.com (Tony Goodloe) (07/13/89)
In article <2596@mit-caf.MIT.EDU>, gavin@mit-caf.MIT.EDU (Gavin C. H. Zau) writes: > Is NFS avaliable on > the Mac IIs? > Gavin Zau Dept of Chemical Engineering, MIT The million-dollar question! If somebody has any information, please let me too. I have been looking for it, and haven't seen a thing. I've seen some dorky gateway solutions, but I want to be able to hang a MAC on Ethernet and connect to our workstations. tony goodloe
amanda@intercon.uu.net (Amanda Walker) (07/14/89)
If you don't want to wait for a native NFS client for the Mac, there's always the Cayman GatorBox. It'll do Ethernet-to-Ethernet protocol translation between AppleShare and NFS. It's slower than a native implementation will be, of course, but it does work and you can buy it now, both of which have distinct advantages sometimes :-). -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
kdb@intercon.uu.net (Kurt Baumann) (07/15/89)
There has been a lot of talk about NFS on the Mac. The question I have for you folks is what is everyone willing to pay for such a beast? I have no idea of what Apple is going to be (or if they are even going to sell/have one) asking, but I thought it an interesting question. Thanks for your time! -- Kurt Baumann InterCon Systems Corporation 46950 Community Plaza Suite 101-132 Sterling, VA 22170 Phone: 703.450.7117
dsill@ark1.nswc.navy.mil (Dave Sill) (07/15/89)
In article <1272@intercon.UUCP> Kurt Baumann <kdb@intercon.uu.net> writes: >There has been a lot of talk about NFS on the Mac. The question I have for >you folks is what is everyone willing to pay for such a beast? I have no >idea of what Apple is going to be (or if they are even going to sell/have >one) asking, but I thought it an interesting question. This is a particularly timely topic for me. I'm in the process of coming up with a plan (gag) for integrating Macs, PCs, and workstations in a UNIX, Ethernet, TCP/IP, NFS, X Window System environment. (With VMS/DECnet/Netware to come) The local Mac proponent believes in the Appletalk/Gatorbox answer. I'd rather have the Macs hooked up directly to the Ethernet, like the rest of the systems, and bag the whole Appletalk scene. Am I dreaming that this will ever be feasible? I don't even know if Apple's Mac NFS will work with an Ethernet card. Then there's the problem of Macs that can't take an Ethernet card. Should we bite the bullet and deal with what I consider a kludgey solution? -- Dave Sill (dsill@relay.nswc.navy.mil)
time@oxtrap.sendai.ann-arbor.mi.us (Tim Endres) (07/19/89)
>> Many questions concerning MacNFS
Being the original author of MacNFS at CITI UofM, maybe I can clear
some things up.
One) MacNFS versus AppleShare
When we started the MacNFS project more than three years ago, we
had to chose between implementing NFs protocols on the Mac or
implementing AppleShare protocols in Unix. We chose to implement the
NFS protocols on the Mac for "open-systems" reasons. CAP implemented
the AppleShare protocols (and nicely I might add).
AppleShare will ALWAYS beat NFS protocols for the Macintosh.
Without getting too deep into details here, suffice it to say that the
mapping of Macintosh files to the Unix domain is not a simple task.
You must keep tracks of the three forks (Data, Resource, Finder).
You must answer many "very brain-damaged" interface calls. The biggest
head-ache was the repetetive "GetFileInfo()" in "index-mode" that
killed any file server whenever the Finder went into its display mode.
Since the NFS protocol was/is (and for good reason) limited, we
had to make *many* network calls to NFS to implement even a *single*
GetFileInfo() call. AppleShare, on the other hand, gets the
complicated Macintosh calls on the Unix side, completes any necessary
"kludges" on the Unix side and returns the answer !All in one network
call!. So MacNFS will never compete with this advantage.
Two) Where is MacNFS
Well, you can blame 9 months of its delay on Bert Herzog at CITI!
He sat on finished, released code and documentation for 9 months,
because "I don't know who to send it to at Apple.". Thanks Bert.
Apple seems unprepared to meet an original deadline for the release
of MacNFS. Why? Well, I could never get it to work 100%!!!
We did not have the Finder source code, and the Finder did things that
did not match the IM docs, and we could get no answer from Apple
Support. I would have thought that internally they could produce this
themselves, but apparently they understand their code very little. Or,
there are other reasons, I can NOT speak for Apple. MacNFS is a very
complicated beast, even if you have source to the Finder and MacOS.
Three) Do you *really* want MacNFS
YES you do. It may not be the best performance package but it is on
every unix box going. CAP is a *very* good facility, but not commercial.
Apple, please get MacNFS out in the hands of your users. It has been
stalled long enough. It seems a shame for such a large amount of work
(paid for by Apple) to sit on a shelf.
Tim Endres.tim@hoptoad.uucp (Tim Maroney) (07/20/89)
Thanks to Tim Endres for his very informative message on MacNFS. It may be of interest to some people that TOPS, A Sun Microsystems Company, was slated from the time of the acquisition by Sun to produce a Macintosh NFS, and to replace its current product TOPS with this Macintosh NFS. Last year, this attempt was abandoned. There are simply too many technical obstacles to producing a good NFS client or server that is compatible with the Macintosh file system. The efficiency constraints imposed by the RPC model are one major problem; the lack of flexibility of the NFS protocol is another. TOPS did negotiate with Sun over changes in the NFS protocol that would allow efficient operation with the Macintosh file system. However, these negotiations came to naught because of blocking on the Sun side. There never will be a good Macintosh NFS product, without major changes to the NFS protocol. Those changes will not happen. I don't mean to sound like a broken record here, but the fact is that NFS is *not* well suited to inter-operating-system environments. It works very well between UNIX systems, tolerably well between UNIX and the similarly ultra-simple MS/DOS file system. It does not work well when there is a complex file system like Macintosh or VMS involved. It can be made to work, but only with a great deal of difficulty and a very user-visible performance penalty. The supposedly inter-OS nature of NFS is a fabrication (albeit a sincere one) of starry-eyed Sun engineers; this aspect of the protocol was announced long before even a single non-UNIX implementation was done. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "There are no Famous People on the net. Only some of us with bigger mouths than others." -- Dan'l Danehy-Oakes, The Roach
amanda@intercon.uu.net (Amanda Walker) (07/20/89)
In article <8058@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > There never will be a good Macintosh NFS product, without major changes > to the NFS protocol. Those changes will not happen. This seems a little strong. I would agree that there will never be a good *simple* NFS product for the Mac without protocol changes, because there is not a simple mapping between the Macintosh file system and a UNIX-style file system (or much of anything else, for that matter :-)). However, I think that products like AUFS, the GatorBox, and others have shown that it is possible to do it acceptably well. The biggest problem I can see in implementing a good native Mac client NFS is simply one of size. Not because of RPC & XDR, which aren't too bad if you look at them as notational aids rather than implementation specs, but because the client code will have to maintain a fair amount of local state in order to buffer things well and avoid lots of network traffic. With UNIX or MS-DOS, you can get by with a pretty dumb client. With the Mac OS you have to do more work, which has good points and bad points, one of the bad points being that it will take longer to do well. NFS in general is all too healthy, and eventually someone will take the time and money to do a good Macintosh implementation. It would be nice if this "someone" turned out to be Apple, but I'm reserving judgement for now. Sigh. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
amanda@intercon.uu.net (Amanda Walker) (07/20/89)
I'd like to add to an article I just posted, in which I responded to Tim Maroney and said that a good native Mac NFS client is possible, even if difficult. After discussion with one of my co-workers, it occurred to me that this article might have given the impression that I think that such a product would be a good thing. I do not. NFS is barely capable of supporting a UNIX workstation, and as long as that's what it is used for, it's not too annoying. However, it doesn't even provide full UNIX file system semantics, much less anything approaching the Macintosh file system. Granted, this can be worked around by putting more code into the client, but this has it's own disadvantages. Even though it provides a usable interim file service solution for Sun, I would not recommend that anyone use it for Macintosh file service, at least in any more serious way than as a convenient way to transfer files between machines. Just thought I'd set the record straight :-). -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda
tim@hoptoad.uucp (Tim Maroney) (07/23/89)
In article <8058@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > There never will be a good Macintosh NFS product, without major changes > to the NFS protocol. Those changes will not happen. In article <1289@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >This seems a little strong. I would agree that there will never be a good >*simple* NFS product for the Mac without protocol changes, because there >is not a simple mapping between the Macintosh file system and a UNIX-style >file system (or much of anything else, for that matter :-)). However, I >think that products like AUFS, the GatorBox, and others have shown that >it is possible to do it acceptably well. I don't know. We are still in the position of giving the Gatorbox people more time to get their software together -- at last report it was still showing remarkable promise but too flaky to depend on. I'm not sure what you mean by AUFS. Is that the A/UX file system? If so, it still has a number of serious problems, like letter casing. >The biggest problem I can see in >implementing a good native Mac client NFS is simply one of size. Not because >of RPC & XDR, which aren't too bad if you look at them as notational aids >rather than implementation specs, but because the client code will have to >maintain a fair amount of local state in order to buffer things well and avoid >lots of network traffic. Oooh, a stateful NFS implementation; there goes one of the protocol's big advantages right there. Hacking around statelessness sounds like a pretty awful problem to me, since there are no built-in synchronization mechanisms to allow you to verify the state you're keeping. On the other hand, if you don't keep state, then as you pointed out, the efficiency plummets as multiple NFS requests are required to satisfy frequently called single MacOS file system traps. You do have an interesting point about using RPC and XDR as notational specs more than as actual protocols. Has anyone here actually done an implementation this way? Some of RPC deals with transport level details rather than notation, so it can't be completely eliminated; and it's my impression that disentangling RPC's notational aspects from the rest of the system is not as easy in practice as it sounds in theory. I no longer have copies of RPC/NFS source code and I can't say for sure. I did look at this when I was working for TOPS, but there were some fairly serious technical problems involved, the details of which I have since repressed by classical Freudian mechanisms. I *will* note that eliminating RPC and XDR from NFS requires a complete rewrite of NFS rather than basing the implementation on Sun's source code, which is a serious obstacle in itself. >With UNIX or MS-DOS, you can get by with a pretty >dumb client. With the Mac OS you have to do more work, which has good points >and bad points, one of the bad points being that it will take longer to do >well. Another of the bad points, as I've noted, is that the extra work you are proposing may not even be feasible under the protocol. State caching in a stateless protocol is a pretty hard problem to solve, and may be insoluble without protocol extensions. If you're going to do the protocol extensions, then there are better ways of going about it than this. If you do make your implementation stateful somehow, then you lose crash resistance. >NFS in general is all too healthy, and eventually someone will take the time >and money to do a good Macintosh implementation. It would be nice if this >"someone" turned out to be Apple, but I'm reserving judgement for now. Lots of time and money have already been thrown at the problem by both Sun and Apple. So far nothing good has come out of it. I think that's a pretty clear indication for the future. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I am convinced that cross-posting is an evil Satanic plot." -- Eugene Miya on soc.net-people, misc.headlines, misc.kids, misc.misc, news.misc, and soc.misc
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (07/24/89)
In article <8100@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <1289@intercon.UUCP> amanda@intercon.uu.net (Amanda Walker) writes: >>The biggest problem I can see in >>implementing a good native Mac client NFS is simply one of size. Not because >>of RPC & XDR, which aren't too bad if you look at them as notational aids >>rather than implementation specs, but because the client code will have to >>maintain a fair amount of local state in order to buffer things well and avoid >>lots of network traffic. > >Oooh, a stateful NFS implementation; there goes one of the protocol's >big advantages right there. Hacking around statelessness sounds like a >pretty awful problem to me, since there are no built-in synchronization >mechanisms to allow you to verify the state you're keeping. On the >other hand, if you don't keep state, then as you pointed out, the >efficiency plummets as multiple NFS requests are required to satisfy >frequently called single MacOS file system traps. You're missing the whole point, Tim. Saying that NFS is a "stateless protocol" doesn't mean that nobody's keeping any state anywhere. How could it? File systems are repositories of state, that's why we use them :-) The key point about NFS is the way in which the state is managed. In particular, an NFS server does not need to maintain any per-client state (though it may choose to for performance reasons). The client retrieves file system state from the server (encoded in things like file handles and directory cookies) and constructs requests which incorporate this state. So in a sense we have a distributed state model: the client may, for example, look up a file by name and the server returns a chunk of state, X, which it promises can be used at any point in the future (except, etc....) to reference that file. Obviously X is constructed in terms of the server's file system state. Equally obviously, as long as the client needs to access the file it should retain a copy of X. In PC-NFS, if a client performs a file open on an NFS drive, we need to fill in an FCB for the file. A quick count on the fingers reveals that there isn't enough room in an FCB to store a file handle. So we have to cache the file handle itself and store a reference to the cache entry in the FCB. No big mystery, no "Hacking around statelessness", just simple engineering. And yes, there are ragged edges to such implementations. Even the Microsoft redirector has to play such games, and can ocasionally be spoofed by particular sequences of requests. In PC-NFS and other personal computer NFS implementations, it is certainly true that you have to issue multiple NFS requests to satisfy single local file system requests. Caches are a way of offsetting the performance degredation you'd otherwise suffer. Even Unix uses them :-) I don't dispute that it's harder for the Mac. The file system is so bizarre and non-orthogonal that it's tough to emulate using ANY heterogeneous distributed file system. But don't give up.... >>NFS in general is all too healthy, and eventually someone will take the time >>and money to do a good Macintosh implementation. It would be nice if this >>"someone" turned out to be Apple, but I'm reserving judgement for now. >Lots of time and money have already been thrown at the problem by both >Sun and Apple. So far nothing good has come out of it. I think that's >a pretty clear indication for the future. Aha! "Post hoc ergo propter hoc." Did it occur to you that the reasons might not be purely technical ones? Geoff Arnold, Internet: garnold@sun.com Manager, PC-NFS Engineering UUCP: ....!sun!garnold PCDS Group, Sun Microsystems Inc. [Seen on a local church: "From sin to self-realization... and back!"]
morgan@Jessica.stanford.edu (RL "Bob" Morgan) (07/25/89)
Tim writes, re Macintosh NFS clients: > Another of the bad points, as I've noted, is that the extra work you > are proposing may not even be feasible under the protocol. State > caching in a stateless protocol is a pretty hard problem to solve, > and may be insoluble without protocol extensions. One form of statefulness in NFS has, of course, been accomplished not by extending the NFS protocol itself, but by adding a Lock Manager protocol, implemented on Unix servers as lockd (how do other systems, eg VMS, implement it, or do they?). Perhaps if MacOS/NFS really requires stateful file service to perform acceptably there could be a "macnfsd" that could handle whatever needs to be handled (ala pcnfsd, which of course is a different animal altogether). Is anyone prepared to be specific about what the problems are and what might be done about them? Macnfsd would of course have to be ported to each NFS server, and would have to trade off between functionality and portability. I can't imagine anyone really defining something like this other than Apple, or an Apple-supported contractor. - RL "Bob" Morgan Networking Systems Stanford
honey@uunet.UU.NET (Peter Honeyman) (08/06/89)
Tim (Maroney), NFS is called a stateless protocol because the server does not maintain state on behalf of the clients. (Other than the contents of files and directories, that is.) Client caching for NFS is as old as the hills. It has been observed that NFS' statelessness wreaks havoc on server performance. (See, e.g., "Scale and Performance in a Distributed File System" by Howard et al. in ACM TOCS 6:1, Feb 88.)