Subject: RE: [nfsv4] what error to return when there is more than one poss ibility

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 7 May 2003 13:07:10 -0700

The first point is that v4 did not attempt to standardize 
everything so that the kinds of customer issues you referred
to would be addressed.  Even larger than the error priority
issue you raised, is the issue of server fs semantics.  The
spec explicitly takes the position that a large part of 
what the user sees is outside of the scope of the spec.  The
protocol is a way of connecting to the server semantics but
the spec leaves the server free in lots of ways to determine
what those semantics are.  This means that there can be conformant
v4 implementations that lots of people would not choose to use,
because they behave differently than that of other vendors.
I think the error priority issue fits with that approach even
though it would be possible to specify and test error priority
conformance.  However, RFC 3530 does not do that so the matter
for v4.0 is closed.

I haven't looked in detail but I think it would be possible to
address these sorts of issues in a minor version, but I would
expect a lot of resistance to moving that direction.  That
resistance wouldn't be coming mainly from me.  I'm prepared to 
adapt to a reasonable specification of this stuff.  We've done 
this in the past for v3, except we didn't use a spec.  We made an
effort to do the same thing Solaris did so I don't expect this
to be that difficult for us.  It's just that there are lots of
possible implementations out there there that may call something
external to do things that I have control over.  Do we want or need
to declare these "non-conformant"?

So here's a proposal.  Do your conformance tests but spin it a
bit differently.  Rather than specifying the "correct" behavior 
make it a testing tool to see what behaviors are out there.
If all (or most major) vendors agree, then let's publish an
informational RFC with some suggested practices (not binding
but people who have the choice woudl normally follow these).
Where there are differences let's try to come up with a common
position and reduce customer problems.  If there were an
approach to this issue that made sense, I'd follow it and
most people probably would even if it were not an issue 
of spec conformance.    

-----Original Message-----
From: Carl Burnett [mailto:[email-masked]]
Sent: Wednesday, May 07, 2003 10:39 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: RE: [nfsv4] what error to return when there is more than one
possibility

Dave,

Thanks for the reply.

I have to respectfully disagree. I think its very important that the 
protocol specify the order of error checks and the appropriate error that 
must be returned. The difference in my example below is EROFS versus 
EACCES to the application on the client. Often the customer feedback we 
get on NFS has to due with differences in behavior compared to other NFS 
vendors. This includes everything from function, to admin methods, to 
command args, to errors applications get. I think it is important, and 
that ultimately it should be possible to produce a conformance suite that 
verifies a server's error behavior.

On the second question of deny_write against a RO file system, I share 
your opinion.

Again, thanks very much,
Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

"Noveck, Dave" <[email-masked]>
05/07/2003 09:09 AM

        To:     Carl Burnett/Austin/IBM@IBMUS, <[email-masked]>
        cc: 
        Subject:        RE: [nfsv4] what error to return when there is more
than one possibility

I think the spec makes no requirement in this regard, and as 
far as I'm concerned that's a good thing.  Doing otherwise 
moves too far in the direction of specifying the implementation, 
at least for my taste. 
> As a related question, should an open with (access_read, deny_write) be 
> allowed against a read-only file system? 
I don't see why not.  You are asking him to not allow anyone to open 
the file for write, and there is no problem for him in doing that. 
I don't see giving him an error, just because your request is 
superfluous.  Why should you force the client to have to look at 
the read-only-ness of the fs and modifiy his open requests? 
-----Original Message----- 
From: Carl Burnett [mailto:[email-masked]] 
Sent: Wednesday, May 07, 2003 9:49 AM 
To: [email-masked] 
Subject: [nfsv4] what error to return when there is more than one 
possibility 

I have a question about what error a server should return when there are 
multiple possibilities. For example lets take open: 
A client sends an OPEN to open a file for write access and deny read 
The file is already opened for read by another open owner 
The file system is a read-only file system 
Should NFS4ERR_ROFS or NFS4ERR_SHARE_DENIED be returned? 
In the above example, assume the open_owner (and thus the clientid) data 
is valid. So in that case the client's lease should be renewed. I think 
this means a server must at least do a bit of state management processing 
even when other basic checks result in errors. Is that correct? 
As a variation on the above case, if the seqid where bad, should 
NFS4ERR_ROFS or NFS4ERR_BAD_SEQID be returned? 
The general question is, which class of errors takes precedence, state or 
non state errors? If this is covered in the RFC, please point me at the 
appropriate spot(s). I want to bookmark it. 
As a related question, should an open with (access_read, deny_write) be 
allowed against a read-only file system? 

Thanks, 
Carl 
Carl Burnett 
AIX Kernel Architecture - Distributed File Systems 
(512) 838-8498, TL 678-8498 
(please reply to [email-masked]) 
_______________________________________________ 
nfsv4 mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/nfsv4 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4