Re: [nfsv4] Last call for RFC3530bis-13 (ends on Sept 2nd)

[Trond Myklebust <[e-mail]>]

On Thu, 2011-08-18 at 11:07 -0400, J. Bruce Fields wrote: 
> On Wed, Aug 17, 2011 at 01:30:28PM -0500, Thomas Haynes wrote:
> > 
> > On Aug 17, 2011, at 8:05 AM, Trond Myklebust wrote:
> > 
> > > 
> > > Does it contain any advice on the OPEN return value when applied to a
> > > file that is not a regular file, symlink or directory? I'll be back in
> > > active duty and able to check for myself tomorrow, but I thought I'd
> > > draw it to your attention now.
> > > 
> > 
> > I assume you are speaking with respect to the recent thread:
> > 
> > Re: [nfsv4] open() of device special files
> > 
> > And the answer would be no, we made no changes from 3530
> > there.
> > 
> > You want to add text to the effect to return NFS4ERR_SYMLINK
> > on an OPEN of an incorrect type?
> 
> Also not a spec issue unless this goes unfixed in our implementations,
> but note rfc 5661 requires NFS4ERR_WRONG_TYPE in the case of OPEN of a
> device (p. 455 in the OPEN implementation section, "If the component is
> neither of those but not an ordinary file, the error NFS4ERR_WRONG_TYPE
> is returned.")
> 
> One other 3530bis question:
> 
> I'm trying to decide where else the server could return NFS4ERR_SYMLINK.
> 3530bis says COMMIT, LOOKUP, LOOKUPP, OPEN, READ, WRITE.
> 
> I wonder about:
> 
> 	CLOSE, OPEN_CONFIRM, LOCK, LOCKU, LOCKT: as with READ, WRITE,
> 	and COMMIT, these cases where the client should have known
> 	better, and we may as well allow (but not require)
> 	NFS4ERR_SYMLINK, as we do NFS4ERR_ISDIR.  (Also NFS4ERR_SYMLINK
> 	is on the error lists for some of these in rfc 5661).
> 
> 	CREATE, READDIR, REMOVE, RENAME, SECINFO, possibly some others:
> 	currently require NFS4ERR_NOTDIR.  I wonder if NFS4ERR_SYMLINK
> 	should also be allowed.  I guess these are also buggy-client
> 	cases, so I think it's safely left up to the implementation
> 	whether to return INVAL, NOTDIR, or SYMLINK.

I can live with those returning NFS4ERR_INVAL. Those are all cases where
the error applies to an invalid object which was passed in the form of a
filehandle. IOW: the client can and should know better.

> (And, a really nitty nit: why are the page numbers in the table of
> contents at
> 
> 	http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-13
> 
> off by one?)

Are they? They seem correct to me. Remember that RFCs list the page
number at the bottom of the page and not the top.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[e-mail]
www.netapp.com