From: Benny Halevy (bhalevy@pillardata.com)
Date: 06/05/02-09:46:58 PM Z
Subject: RE: Updated revision draft-ietf-nfsv4-rfc3010bis-01-01.txt available
Date: Wed, 5 Jun 2002 19:46:58 -0700
Message-ID: <22A013D3B119FA47ABE88EF314C8E68E0C92EA@SJEX01.trans.corp>
From: "Benny Halevy" <bhalevy@pillardata.com>
Spencer,
1. OPEN and LOCK state mechanism is documented inconsistently with respect to
open_owner4 and lock_owner4 and other related structures (open_to_lock_owner4, etc.) in
Section 2.1 (Basic Data Types), Section 8.1 (Locking), Section 14.2.10 (LOCK),
Section 14.2.16 (OPEN), and Section 18 (RPC definition file). This is a major issue
in the spec., what way (and when) are you going to resolve it?
2. In Section 1.2 (General Definitions) stateid and verifier are documented
as "A 64-bit quantity" which is inconsistent with the rest of the document.
3. It is not clear what should be the result of LOOKUPP on a named attribute directory.
Should it refer to the object associated with that named attribute directory (makes sense
to me) or should it refer to the parent directory of that object, which could be implied
from the documentation "LOOKUPP assigns the filehandle for its parent directory to be the
current filehandle".
4. In Section 14.2.10 (LOCK):
4.1. what is 'access' in the result synopsis?
4.2. LOCK4denied definition is inconsistent both with LOCKT's (in the next section)
and with the .x file.
5. In Section 14.2.23 (READ), 14.2.36 (WRITE): order of arguments in the synopsis is wrong
(stateid should be pushed forward).
6. In Section 14.2.27 (RENAME): synopsis could use a comma after 'oldname'
7. In Section 14.2.32 (SETATTR): stateid is missing from the synopsis.
Best Regards,
Benny Halevy
Pillar Data Systems
P.S. Some ideas to think about (feel free to skip this part, it is probably too late for
major changes in this version anyhow...)
* The OPEN call is highly overloaded with create and delegation issues which makes the
documentation and protocol definition quite hard to understand. Separating the call into
OPEN and OPENCREATE could considerably simplify things for the create case (assuming
OPEN is documented well :-) as well as solving some potential ambiguities regarding
claim_type which doesn't seem to be applicable to the CREATE case.
* Allowing OPEN of a regular file (if the CURRENT_FH refers to one) in the CLAIM_NULL case
could be very useful to save a name lookup operation on the server when the client can
provide the final filehandle.
* The name for OPENATTR is misleading; although it can also create the named attribute
dir like OPEN it establishes no state on the server, which is the essence of OPEN.
I think a better name for it would be LOOKUPATTR or something like that, while the create
case could be separated into another call.
* What is the reason for not supporting creation of regular files with the CREATE operation?
It seems like stateless create is penalized by having to OPEN (with some share reservation
which could be irrelevant if the client is not opening the file for I/O) and CLOSE the newly
created file. It might not be a common client use case, could be used for named locks for
example yet it could be solved elegantly if CREATE call would support NF4REG similar to NFSv3's
CREATE. In this case CREATE structures could look like the following:
(assuming createattrs may be ignored in the EXCLUSIVE case)
enum createmode4 {
UNCHECKED4 = 0,
GUARDED4 = 1,
EXCLUSIVE4 = 2
};
union createhow4 switch (createmode4 mode) {
case UNCHECKED4:
case GUARDED4:
void;
case EXCLUSIVE4:
verifier4 createverf;
};
union createtype4 switch (nfs_ftype4 type) {
case NF4REG:
createhow4 how;
case NF4LNK:
linktext4 linkdata;
case NF4BLK:
case NF4CHR:
specdata4 devdata;
case NF4SOCK:
case NF4FIFO:
case NF4DIR:
void;
default:
void; /* server should return NFS4ERR_BADTYPE */
};
struct CREATE4args {
/* CURRENT_FH: directory for creation */
createtype4 objtype;
component4 objname;
fattr4 createattrs;
};
struct CREATE4resok {
change_info4 cinfo;
bitmap4 attrset; /* attributes set */
};
union CREATE4res switch (nfsstat4 status) {
case NFS4_OK:
CREATE4resok resok4;
default:
void;
};
-----Original Message-----
From: Spencer Shepler [mailto:shepler@eng.sun.com]
Sent: Wednesday, June 05, 2002 3:58 PM
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Updated revision draft-ietf-nfsv4-rfc3010bis-01-01.txt
available
You will find an updated RFC3010 specification at:
http://www.nfsv4.org/rfc3010updates/draft-01-01/draft-ietf-nfsv4-rfc3010bis-01-01.txt
and matching issues list at:
http://www.nfsv4.org/rfc3010updates/issues.html
The goal is to have the issues list completed and the documented
updated by the cut off date for the next IETF meeting. This means to
have the updates completed by June 27th.
I have a few issues to add to the list that have been sent to me
directly but if you have something that is not reflected in the list
above, please let me know so that the item can be added and resolved.
--
Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:50 AM Z CST