Subject: [nfsv4] Directory delegation modification

From: "Anatoly Pinchuk" <[email-masked]>
Date: Mon, 12 Oct 2009 21:43:16 -0700

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 14 Oct 2009 11:56:47 -0400

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

-----Original Message-----
From: Anatoly Pinchuk [mailto:[email-masked]] 
Sent: Tuesday, October 13, 2009 12:43 AM
To: [email-masked]
Subject: [nfsv4] Directory delegation modification

Regards,
Anatoly
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Wed, 14 Oct 2009 18:32:21 +0200

> more specific about what sequence of operations you don't think is

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 14 Oct 2009 13:00:15 -0400

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:[email-masked]] 
Sent: Wednesday, October 14, 2009 12:32 PM
To: Noveck, Dave
Cc: Anatoly Pinchuk; [email-masked]
Subject: Re: [nfsv4] Directory delegation modification

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?

Benny

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Wed, 14 Oct 2009 11:17:57 -0700

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

> From: Noveck, Dave [mailto:[email-masked]]
> Sent: Wednesday, October 14, 2009 10:00 AM
> To: Benny Halevy
> Subject: RE: [nfsv4] Directory delegation modification
> 
> OK, I see now.
>

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 28 Oct 2009 11:41:47 -0700

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

>    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

>    gddrnf4_status of GDD4_UNAVAIL and a gddrnf_will_signal_deleg_avail

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.

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