Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!ames!ncar!mephisto!mcnc!rti!dg-rtp!egghead!stukenborg From: stukenborg@egghead.rtp.dg.com (Stephen Stukenborg) Newsgroups: comp.protocols.nfs Subject: Re: NeFS Keywords: NeFS, NFS Message-ID: <1990Jul3.164301.2676@dg-rtp.dg.com> Date: 3 Jul 90 16:43:01 GMT References: <1075@cluster.cs.su.oz> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: stukenborg@egghead.dg.com () Organization: Data General Corporation, Research Triangle Park, NC Lines: 107 In article <1075@cluster.cs.su.oz> bruce@basser.cs.su.oz.au writes: >In light of this limitation it is interesting to note that >Sun are proposing a new (postscript-based) network file >system protocol -- NeFS. >Postscript programs are written on the client, downloaded >to the server which then executes them returning results as desired. It seems that in the first go around, most comments centered around whether or not postscript was a "good" language for implementing the protocol primitives. Little attention was given to other aspects of the NeFS protocol. I would like to throw out a few comments on the paper, mostly because I'm sick of wading through the PC-NFS traffic. The first section of the paper calls out six problem areas of the version 2 NFS protocol, and claims that NeFS addresses them. There are still some large pieces missing from the protocol before it can claim to be operating system independent. 1. Size limitations. Yes, NeFS addresses this by increasing the size of some structures. I assume any new protocol will fix these limitations. 2. Non-idempotent procedures. Well, like the rev. 2 protocol, NeFS still assumes a stateless server implementation. Section 2.3 states "The NeFS protocol does not guarantee idempotent operations per se, but it does allow requests to be assembled that can detect retries of themselves ..." Maybe I'm missing something, but I don't see which NeFS operations aid retransmission detection. How can I detect retransmissions unless there is a unique identifier in the request, and I keep a cache of duplicates (section 3.3.3). What is in the NeFS protocol that solves this problem? Nothing that I can see. (The "valid" operator?) Let's take a simple protocol failing from rev. 2, "exclusive create". How do I build an exclusive create that detects retransmissions? In other words, how do I detect the situation where the client transmits the request, server does exclusive create, server sends reply "success, client never gets the reply, times out and retransmits the request. My exclusive create should return "success". Without a duplicate request cache on the server, it will return "failed - file exists". I guess they have fixed the "remove" idempotent operations by saying that remove succeeds if the entry does not exist. But what about rename? The NeFS protocol does little to address idempotency. 3. Unix bias Well, the draft I have (2/12/90) has several places with Unix bias. Look at the definition of file attributes (4.2.3). Those permission bits are Unix. What about access control lists? Should file permission be dependent on the "ftype" field? The "link" operator is called out in the document as being very Unix-specific. I agree with the statement that the "operator list should be confined to only those operators that all implementations can reasonable expect to implement." So you define a file type "directory", and define operators that deal with directories (e.g. add entry, delete entry, lookup, etc.). Having OS-specific operators is the wrong answer if you are trying define an operating system independent protocol. Although it is really an RPC issure, authentication is something that is given short shrift in the document. Section 3.3.4 says that "authentication information in the environment is conveyed by the interpreter to the NeFS operators to be used in checking access permissions for filesystem objects." I hope they're not assuming AUTH_UNIX authentication like the version 2 protocol did. 4. No access procedure. I assume this makes overt the covert permission hacks in the rev. 2 protocol. (e.g. the server allows the owner of a file to read/write it no matter what the file permissions are set to.) 5. No facility to support atomic filesystem operations. As it stands now, the "lock" operator needs work. "Beware of deadlocks" when nesting locks is the wrong answer. Nor should it be an error to nest locks. The "lock" operator should do deadlock detection. What does the spec mean in the IMPLEMENTATION section when it states "mandatory locking is required for all NeFS clients"? That each filesystem operator is going to get a lock? (e.g. the write operator is going to get an exclusive lock on the file before it writes the data?) Locks are mandatory only if everyone is forced to use them. 6. Performance. You can definitly see where defining NeFS "programs" that can do several serveral remote filesystem operations can be a big win. This seems to be the real strength of an extensible protocol. An extensible protocol is an innovative idea for the next version of NFS. I just think there needs to be more discussion of the "real" protocol issues, rather than whether or not postscript is the proper language to implement an extensible protocol. Steve Stukenborg Data General Corporation 62 Alexander Drive stukenborg@dg-rtp.dg.com Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!stukenborg