Re: [nfsv4] Directory delegation modification

[Benny Halevy <bhalevy at panasas.com>]

On Oct. 14, 2009, 17:56 +0200, "Noveck, Dave" <Dave.Noveck at netapp.com> wrote:
>> It seems that the protocol does not specify if an 
>> already established directory delegation may be 
>> modified. So, it would be beneficial if we agree 
>> on how the server SHOULD/MUST process an attempted 
>> modification.
> 
> See section 10.9.2.  
> 
> Reading it, it does seem that it could be clarified/re-organized a
> little but I think all of the issues are dealt with.  Fundamentally,
> directory delegations are read-only, but we have an associated
> asynchronous notification mechanism to allow environments in which
> delegations would always be recalled to be handled better.
> 
> The penultimate paragraph does deal with an optimization in the case in
> which only one client has a delegation.  In this case the server can
> allow changes initiated by that client without a recall.
> 
> Maybe I'm not understanding your question.  Could you be a little bit
> more specific about what sequence of operations you don't think is
> addressed by the spec.

If I understood Anatoly correctly the spec. doesn't specify the case
where the server receives a GET_DIR_DELEGATION from a client that already
has a dir delegations for the current FH.  Should it be ignored or rejected?

Anatoly suggests to allow this and update the client's dir delegation's
parameters (e.g. gdda_notification_types)

It seems like to update the parameters, the protocol should have had
the stateid in the request args. But it doesn't.

Benny 

> 
> -----Original Message-----
> From: Anatoly Pinchuk [mailto:apinchuk at bluearc.com] 
> Sent: Tuesday, October 13, 2009 12:43 AM
> To: nfsv4 at ietf.org
> Subject: [nfsv4] Directory delegation modification
> 
> 
> It seems that the protocol does not specify if an already established
> directory delegation may be modified. So, it would be beneficial if we
> agree on how the server SHOULD/MUST process an attempted modification.
> Two possible approaches are:
> - Disallow the modification and return an error code if the client tries
> to modify the delegation
> - Allow the modification and replace all existing delegation fields with
> new ones constructed using GET_DIR_DELEGATION arguments
> Has anyone considered this issue?
> 
> Regards,
> Anatoly
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4