Re: [nfsv4] Directory delegation modification

["Noveck, Dave" <Dave.Noveck at netapp.com>]

OK, I see now.

There is clearly an oversight here.  The question is how best to address
it given that we have been through last-call etc.  If we were to decide
that the update of the parameters were the desired behavior, the client
would have to be prepared for this, recognize that he is getting the
same stateid.  There would be probably also have to be some text that
deal with the issues of notifications occurring after they were no
longer appropriate given the change in parameters.

It would be hard to argue that modification was the intention of the
original text, i.e. that that was in somebody's mind but he just
neglected to write it down, and that everybody who reviewed just assumed
the same exact thing, but neglected to note that the text didn't address
this case :->

It is far more reasonable to assume that the author didn't think about
the possibility and forgot to note that you can't request a delegation
when you already have one, or at least not successfully.  Similarly,
everybody who looked at it, until Anatoly did not recognize the
possibility.  The topic sentence is "The GET_DIR_DELEGATION operation is
used by a client to request a directory delegation."  Since it doesn't
say "or modify it" I don't think it can be argued that this is somehow
implicit.

So my proposal is that you don't return an error (since, to be strict,
adding a new error is a protocol change and we don't want to have
those).  I suggest adding the following text as a new last paragraph in
section 18.39.3.

   When a client makes a request for a directory delegation
   while it already holds a directory delegation for that directory
   (including the case where it has been recalled but not yet
   returned), the server MUST return an indication that a
   delegation for that directory is not available, with a 
   gddrnf4_status of GDD4_UNAVAIL and a gddrnf_will_signal_deleg_avail
   of FALSE.  

I think that adding a way modify an existing directory delegation is a
perfectly reasonable thing to do in v4.2.

-----Original Message-----
From: Benny Halevy [mailto:bhalevy at panasas.com] 
Sent: Wednesday, October 14, 2009 12:32 PM
To: Noveck, Dave
Cc: Anatoly Pinchuk; nfsv4 at ietf.org
Subject: Re: [nfsv4] Directory delegation modification


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
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4