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

cburnett@us.ibm.com

Subject: Re: [nfsv4] Server response when CLAIM_DELEGATE_PREV is not supported
Message-ID: <OF9353C2F9.3F0B9BB3-ON87256CE9.00650F17@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
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 cburnett@us.ibm.com)

Mike Eisler <mike@eisler.com>
03/14/2003 11:13 AM

        To:     Carl Burnett/Austin/IBM@IBMUS
        cc:     nfsv4@ietf.org
        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 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