Subject: Re: [nfsv4] Current stateid

From: Spencer Shepler <[email-masked]>
Date: Fri, 17 Mar 2006 16:16:58 -0600

This issue has been created to track inclusion of current stateid:

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue5

On Wed, David Robinson wrote:
> 
> On Feb 15, 2006, at 1:07 PM, Benny Halevy wrote:
> >By the way, many moons ago there was a discussion that didn't end  
> >anywhere about introducing a "current stateid" concept (e.g with a  
> >special stateid value that will refer to the last stateid returned  
> >in the same compound RPC).  With such a mechanism one could modify  
> >or read data atomically with a namedattr in the same compound.  Is  
> >there still interest in trying to add this to the protocol?
> 
> Spencer has been beating me up on summarizing where we
> were on that proposal.
> 
> Key question:  Do we want to go forward with this? In 4.1?
> 
> My I-D has expired, but I can resubmit it if need be.
> 
> The previous questions could be summarized as:
> 
> 1) What about stateid hierarchy and ordering?
> 
>    In the only case where two stateid's can be returned (OPEN)
>    the next usage with a special stateid will always be unambiguous
>    which stateid to use. Ops requiring a delegation stateid should
>    use it, all others use the open stateid. Brought up the interesting
>    use case where the client could follow an OPEN with a
>    DELEGRETURN in the same COMPOUND to efficiently always reject
>    delegations.
> 
> 2) The wording in section 2 that operations that do not return
>    a stateid MUST zero the current stateid is overly restrictive.
> 
>    Yes, that is just bad language.  The intent was that any operation
>    that changes the current filehandle without returning a stateid
>    (e.g. PUTFH) MUST zero the current stateid. Other ops like
>    GETATTR should not affect it.
> 
> Other than those clarifications, and some minor wording issues,
> there were no serious objections.
> 
> 	-David
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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