Re: [nfsv4] Directory delegation modification

["Anatoly Pinchuk" <apinchuk at bluearc.com>]

The interpretation provided by Benny is correct. As for the proposed
protocol adjustment, it addresses the main problem and describes how an
attempted directory delegation modification MUST be processed in v4.1.
Allowing the client to modify an existing delegation would be nice, but
it definitely requires more efforts and can be postponed.

Anatoly


> -----Original Message-----
> From: Noveck, Dave [mailto:Dave.Noveck at netapp.com]
> Sent: Wednesday, October 14, 2009 10:00 AM
> To: Benny Halevy
> Cc: Anatoly Pinchuk; nfsv4 at ietf.org
> Subject: RE: [nfsv4] Directory delegation modification
> 
> 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