RE: [nfsv4] what error to return when there is more than one possibility

cburnett@us.ibm.com

Subject: RE: [nfsv4] what error to return when there is more than one possibility
Message-ID: <OF0C239964.543DB124-ON87256D1F.004F4655@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Wed, 7 May 2003 09:39:02 -0500

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 cburnett@us.ibm.com)

"Noveck, Dave" <Dave.Noveck@netapp.com>
05/07/2003 09:09 AM

        To:     Carl Burnett/Austin/IBM@IBMUS, <nfsv4@ietf.org>
        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:cburnett@us.ibm.com] 
Sent: Wednesday, May 07, 2003 9:49 AM 
To: nfsv4@ietf.org 
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 cburnett@us.ibm.com) 
_______________________________________________ 
nfsv4 mailing list 
nfsv4@ietf.org 
https://www1.ietf.org/mailman/listinfo/nfsv4 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4