Xref: utzoo comp.protocols.nfs:312 comp.sys.mac.programmer:8119 Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!sun-barr!newstop!east!hinode!geoff From: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Newsgroups: comp.protocols.nfs,comp.sys.mac.programmer Subject: Re: NFS and Mac IIs Message-ID: <613@east.East.Sun.COM> Date: 24 Jul 89 16:58:15 GMT References: <5458@b11.ingr.com> <2596@mit-caf.MIT.EDU> <1272@intercon.UUCP> <8058@hoptoad.uucp> <1289@intercon.UUCP> <8100@hoptoad.uucp> Sender: news@east.East.Sun.COM Reply-To: geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) Followup-To: comp.protocols.nfs Organization: Sun Microsystems, Billerica MA Lines: 68 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!"]