Xref: utzoo comp.protocols.nfs:285 comp.sys.mac.programmer:7757 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy.jpl.nasa.gov!decwrl!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.protocols.nfs,comp.sys.mac.programmer Subject: Re: NFS and Mac IIs Message-ID: <8100@hoptoad.uucp> Date: 22 Jul 89 18:25:04 GMT References: <5458@b11.ingr.com> <2596@mit-caf.MIT.EDU> <1272@intercon.UUCP> <8058@hoptoad.uucp> <1289@intercon.UUCP> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 74 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