[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [nfsv4] Directory delegation modification

To: nfsv4 at ietf.org
Subject: Re: [nfsv4] Directory delegation modification
From: "Mike Eisler" <mre-ietf at eisler.com>
Date: Wed, 28 Oct 2009 11:41:47 -0700
Delivered-to: nfsv4 at core3.amsl.com
In-reply-to: <6AD91E4EBDFF734B9035AA1DCD0965E5028FE8EF at RTPMVEXC1-PRD.hq.netapp.com>
List-archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-help: <mailto:nfsv4-request@ietf.org?subject=help>
List-id: NFSv4 Working Group <nfsv4.ietf.org>
List-post: <mailto:nfsv4@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
References: <6AD91E4EBDFF734B9035AA1DCD0965E5028FE8EF at RTPMVEXC1-PRD.hq.netapp.com>
User-agent: SquirrelMail/1.4.19

Finally getting back to NFSv4.1 after a diversion into v4.2.

> 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),

I think the above should be:

   (including the case where it has been recalled but not yet
   returned by the client or revoked by the server),

> 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.

So what happens to the existing directory delegation? Is it still intact?
I think it is, and so suggest appending this sentence.

   The delegation the client held before the request remains intact, and
   its state is unchanged. The current stateid is not changed.



On Wed, October 14, 2009 10:00 am, Noveck, Dave wrote:
> 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
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

References:
- Re: [nfsv4] Directory delegation modification
  - From: Noveck, Dave

Prev by Date: [nfsv4] IETF76 NFSv4 draft agenda posted
Next by Date: [nfsv4] [FedFS] meeting agenda (10/29)
Previous by thread: Re: [nfsv4] Directory delegation modification
Next by thread: [nfsv4] [FedFS] meeting agenda (10/15)
Index(es):
- Date
- Thread