Subject: RE: Minor Inter-operability stuff

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 1 Jul 2002 07:49:57 -0700

> I've been doing some testing of the Univ. of Michigan Linux V4 client against
> my server and I've bumped into the following:
> 
> - The argument to LOOKUP has changed from a "pathname" to a "component". Is
>   this a permanent change to RFC3010?

I guess nothing is permanent until we go through Proposed Standard (again).
Draft Standard, and Standard, but I certainly expect things to stay that
way.

This first happened in the Nov 2001 spec, which has been the basis for
bakeoff and other interoperability testing for a while.

We're trying to shut down incompatible protocol changes.  I know there's
one that will be in the latest spec (Spencer has this under preparation
now) and there may have been a few others between Nov 2001 and now.  I
believe that that spec (call it the July 2002 spec) will be what is 
tested at the bakeoff in August.  Although there may be clarifications
and a few new error codes in subsequent the revisions, the message formats 
are will not change past that point, barring something absolutely
extraordinary happening.  A number of people have said things on 
the order of "Over my dead body", anyway. 
   
As I recall the change of LOOKUP to a component happened when people 
started to ask for information about partially successful lookups and
wouldn't it be nice if they could get information about how far it
got that allowed them to resume the lookup (after interpreting a symlink,
for example), rather than an unhelpful "Gee your lookup failed".  When 
satisfying those people started to make LOOKUPres kind of repulsive,
it was pointed out that COMPOUND allowed them to decide the information
they got by doing multiple single-component lookups.  At which point the
idea of LOOKUP taking a pathname seemed kind of useless since it was
only for those who wanted to do a multiple-component lookup and did not
want any intermediate results in the event of partial success, and it wasn't
clear such people existed.
 
- The Linux client wants the RAWDEV attribute to be returned for what seems
  like all files/directories. Does this make sense for non-special files?
  (and what should it be? The same as fsid?)
- a symlink op has no attributes associated with it. (Most V2/3 clients do
  seem to provide a mode.)

 ...

Now, for a couple that I'm not so sure about w.r.t. semantics.
- Unless I disable callbacks, the client sometimes hangs waiting for a
  callback during writing of large files. (My server doesn't do callbacks
  yet and I haven't figured out quite what is going on w.r.t. delegation.
  Are callbacks only expected when Delegation occurs?)

 ...

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 1 Jul 2002 08:06:08 -0700

The last reply was incomplete (hit send when I shouldn't have).  This
should be read in preference to that.

We're trying to shut down incompatible protocol changes.  I know there's
one in the latest spec (http://www.nfsv4.org/rfc3010updates/draft-01-04/draft-ietf-nfsv4-rfc3010bis-01-04.txt) and there may have been a few others between 
Nov 2001 and now.  See http://www.nfsv4.org/rfc3010updates/index.html
for the recent spec history.  I believe that the new spec will be what is 
tested at the bakeoff in August.  Although there may be clarifications
and a few new error codes in subsequent the revisions, the message formats 
will not change past that point, barring something absolutely
extraordinary happening.  A number of people have said things on 
the order of "Over my dead body", anyway. 
   
As I recall, the change of LOOKUP to a component happened when people 
 
>   (and what should it be? The same as fsid?)

My server has always returned zero for RAWDEV for non-special files and the
Linux client had no problem.  I'm guessing but I bet a random number would
do as well.

> - a symlink op has no attributes associated with it. (Most V2/3 clients do

The philosophy is that if you want attributes, do a GETATTR as part of the
COMPOUND. 

 ...

>   Are callbacks only expected when Delegation occurs?)
 
Callbacks are only expected when delegation occurs.  However, even when
callbacks are expected, the client shouldn't wait one.  It is up to the
server when to recall a delegation.  The cleint can return a delegation
that even if it has not been recalled.

 ...

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 14:02:02 -0500

On Sun, [email-masked] wrote:
> Hi,
> 
> I've cc'd the main nfsv4-wg, since some of these are things others might
> have opinions on, or maybe be interested in hearing about.
> 

>   (and what should it be? The same as fsid?)

Technically, since the rawdev attribute is in the recommended set, all
clients must be able to deal with the absence of that attribute for a
particular server.  Obviously for device files it should be present
and a server that did not provide it would not be very friendly.

> - a symlink op has no attributes associated with it. (Most V2/3 clients do

For the CREATE operation, attributes were added later so the argument
is now present for the CREATE operation.  However, the server may not
use the attributes for things like symlink.

> - At the beginning of the old connectathon basic test8, the client gets
>   upset when an inode changes from 100666->120755 (from a regular file to
>   a symbolic link). I know the fileid has been reused with a different
>   generation#, which would be ok for V2/3. For V4, should something else
>   change when a node (fileid#) is reused? Are File Handles still T stable?
>   (That seems to be vaguely hinted at in RFC3010, section 4.)

Yes.  Persistent filehandles should behave the same as filehandles do
for v2/v3.

> Oh, and I assumed the NFS4ERR_EROFS return value for Openattr is just a
> typo for NFS4ERR_ROFS?

This has been corrected in the updates already.

-- 
Spencer