Subject: Re: [nfsv4] Server response when CLAIM_DELEGATE_PREV is not supported

From: Carl Burnett <[email-masked]>
Date: Fri, 14 Mar 2003 12:43:44 -0600

Thanks for the reply Mike,

The suggested approach seems reasonable, even with the confirm aspect. If 
the WG agrees with this (or what ever is decided), detail like this must 
make it into the protocol spec. This is too important to be in some other 
document, an email archive, or in a few peoples heads. Should some issue 
be logged to get this in at the next opportunity?

On a similar question, if a client incorrectly sends an 
CLAIM_DELEGATE_PREV or CLAIM_DELEGATE_CUR to a server that has never 
granted the client a delegation, would NFS4ERR_INVAL be the appropriate 
return? If so,

Would the open owner sequence id be incremented (assuming the provided 
owner and seqid where valid)?

Would the client's lease be updated (assuming good owner and seqid 
information)?

Carl

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

Mike Eisler <[email-masked]>
03/14/2003 11:13 AM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     [email-masked]
        Subject:        Re: [nfsv4] Server response when CLAIM_DELEGATE_PREV is not supported

Let me suggest this, and allow the wg to find flaws:

CLAIM_DELEGATE_PREV is used by a client to reclaim a delegation
is had before the client rebooted. The reason why a server would
not support CLAIM_DELEGATE_PREV is if it has implemented
SETCLIENTID/SETCLIENTID_CONFIRM to remove the
client's delegation state. Since OPEN does useful things other
than creating delegations, rather than returning an error, the
server could process the open, but in the open results
returna delegation_type of OPEN_DELEGATE_NONE.
This would tell the client that it's delegation is gone,
and so it can no longer rely on the consistency of
its cache of data for the file.

Unfortunately, this strategy is somewhat at odds with
the requirement that CLAIM_DELEGATE_PREV opens
be unconfirmed. Given that the requirement is there to give
implementations an out from dealing with complexity of recoverying
from unconfirmed opens that returned delegations, the requirement
doesn't apply. No delegation is created, so the server can
prescribe an OPEN_CONFIRM it has to.

Carl Burnett wrote:

>What error should be returned on OPEN when a server does not support 
>CLAIM_DELEGATE_PREV? I never found any specific mention in the spec. The 
>best error fit seems to be NFS4ERR_NOTSUPP, which OPEN discusses for 
>exclusive create semantics. Also a note that the list of errors at the 
end 
>of the OPEN description does not include NFS4ERR_NOTSUPP.
>

Ya know, I think when we do NFSv4.1, we should have the switched unions 
for
every operation result that lists every valid return code. This way, the
rule that the .x fiile is authoritative would carry more weight. We 
should then stop
listing the error returns outside of section 18. No more "defaults" in 
the return results.

>
>
>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

---

From: Mike Eisler <[email-masked]>
Date: Fri, 14 Mar 2003 11:33:04 -0800

> be logged to get this in at the next opportunity?

I agree. I've made a note in a file for the issues you've brought up today.
Adding NOTSUP to the OPEN error list is easy to do before the RFC is 
published, but
adding these clarifications will have to happen outside the RFC.

The big problem is the www.nfsv4.org is gone and we've got no
short term or long term place for such material.

> granted the client a delegation, would NFS4ERR_INVAL be the appropriate 

Perhaps NFS4ERR_RECLAIM_BAD is the more appropriate error here.

> owner and seqid where valid)?

The spec says:

   The client MUST monotonically increment the sequence number for the
   CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
   operations.  This is true even in the event that the previous
   operation that used the sequence number received an error.  The only
   exception to this rule is if the previous operation received one of
   the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
   NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR,
   NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE.

I would adhere to that, and say yes, whether _INVAL or _RECLAIM_BAD is 
returned,
the seqid needs to be increased.

> Would the client's lease be updated (assuming good owner and seqid

The spec says that an OPEN with a valid clientid "cause[s] implicit 
renewal". So, I'd adhere to
that and renew the lease.