Path: utzoo!attcan!uunet!samsung!usc!apple!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent From: brent@terra.Eng.Sun.COM (Brent Callaghan) Newsgroups: comp.protocols.nfs Subject: Re: NeFS Keywords: NeFS, NFS Message-ID: <138602@sun.Eng.Sun.COM> Date: 9 Jul 90 19:17:09 GMT Sender: news@sun.Eng.Sun.COM Lines: 136 References: <1075@cluster.cs.su.oz> <1990Jul3.164301.2676@dg-rtp.dg.com> In article <1990Jul3.164301.2676@dg-rtp.dg.com>, stukenborg@egghead.rtp.dg.com (Stephen Stukenborg) writes: > 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?) NeFS tries not to make too many assumptions about the underlying transport. If the transport takes care of retransmissions and guarantees "at most once" semantics then it's a waste of time having explicit support for it in the protocol. > 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". The client could carry a timestamp with its request and insert it into an attribute like the modification time. A retransmission can be detected firstly by the existence of the file (via the valid operator) then by checking the timestamp (and any other attributes). Ditto for rename or any other filesystem modification request. A better scheme might be the establishment of a duplicate request cache accessible to requests. The client could stash xid's in the cache and make explicit references to the cache to detect retransmissions. > 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? It's a more general issue than just "Unix Bias". How do you design a protocol that supports remote access to a wide variety of filesystems from a wide variety of OS's without generating a monster that nobody would choose to implement ? It's not an easy problem. I don't think there's any difficulty in making NeFS support lots of different filesystems. The difficulty is in finding a "common set" of file attributes and operations that supports interoperability ? This is a worthy goal if the "common set" can be made small and easy to understand and map to. There's not a lot of common ground when it comes to file permissions. Let me have your ideas. > 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. All filesystems in common use support some notion of a directory. Flat filesystems may allow you to operate on "the" directory but reject operations that attempt to create or delete a directory. This is entirely reasonable. The "link" operator sticks out as being Unix-specific but the notion of allowing filesystem objects to have multiple names appears to be generally useful. The "common set" of operations is just an ideal that implementations can attempt to conform to. It's OK to return an ENOTSUPP if the operation has no meaning - just as it is now for NFS clients attempting to create symbolic links on System V filesystems. > 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. No. NFS is not restricted to AUTH_UNIX. It'll support whatever authentication is conveyed by the underlying RPC authentication flavor. There are already implementations of "secure" (public key) and Kerberos authenticated NFS. It's not appropriate for NeFS as a protocol to spell out what's to be used for authentication. It'll use whatever is provided. > 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. Yes. A better design for this operator would be to allow a vector of filehandles to be locked. This would allow the server to order the locks appropriately to avoid deadlock. > 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. Yes. It means that if you hold an exclusive lock, all other clients attempting to use the filehandle will block until the lock is freed. If you hold a non-exclusive lock, Other clients that would change the object that corresponds to the filehandle will block. A lock is limited to the duration of a request. > 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. Right on! -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051