Subject: [nfsv4] Directory Delegation Push - Not Needed

From: Mike Eisler <[email-masked]>
Date: Tue, 6 Nov 2007 02:59:40 -0800 (PST)

To come back to issue Dave describes below,
I think we do not have support the pushing or
notification of directory delegations. So in other
words, nothing more to do.

My reasoning is that because we have no way to establish an "open"
reference on a directory, and because we have to way to open a 
directory for writing, a directory delegation isn't going to be 
denied due to contention with a writer, then we don't need to push 
a delegation (or extend CB_NOTIFY to notify the client that the
contention is no longer present). While it is true a lazy server 
could refuse a directory delegation if the directory is currently 
have a modification (e.g. file create) performed on it, we should 
not complicate the protocol to support lazy servers. The non-lazy 
server would just queue the delegation request after all the
modification requests. The half-way lazy server would just return
NFS4ERR_DELAY (Need to check if NFS4ERR_DELAY is among the list of
errors GET_DIR_DELEGATION can return).

--- "Noveck, Dave" <[email-masked]> wrote:

> I recall that we had a discussion about whether CB_PUSH_DELEG could
> in
> fact
> propagate a delegation requested by GET_DIR_DELEGATION, as opposed to
> delegation
> for non-directory types of objects.  I guess there was also
> implicitly a
> question
> about whether it should be able to do so.
> 
> So on the first point, the answer seems to be "No" since
> CB_PUSH_DELEGargs
> contains an open_delegation4, which doesn't have a provision for a
> lot
> of the
> data returned in a GET_DIR_DELEGATION4resok.  Since this information
> is
> not
> provided on the response to the GET_DIR_DELEGATION or in the
> CB_PUSH_DELEG,
> it doesn't seem that there is a current provision for CB_PUSH_DELEG
> to 
> deliver a directory delegation.
> 
> In fact, there is no provision currently for GET_DIR_DELEGATION to
> promise
> to deliver a directory delegation when the delgation is available
> (i.e.
> there
> is no conflict on that specific object), which would call for
> CB_PUSH_DELEG
> or something like it.  The only provision in which it promises to
> signal
> you
> is when there is resources unavailable, i.e. something will be
> resolved
> by
> CB_RECALLABLE_OBJ_AVAIL. 
> 
> I'm supposing that this structure derives from the fact that there
> are
> no
> write directory delegations and it is thus impossible for there to be
> a 
> hard conflict that would not allow a directory delegation to be
> granted.
> I'm not sure if this logic is valid since it is possible for a server
> not
> to grant a directory delegation because frequent directory changes
> makes
> this not an efficient way to go.  And if that could cause a
> delegation
> to be denied, the situation might be changed when those changes stop.
> 
> Anyway, what I am going to do now is to change CB_PUSH_DELEG so it
> doens't
> reference GET_DIR_DELEGATION and if we want to extend
> GET_DIR_DELEGATION
> 
> and CB_PUSH_DELEG to support this, we can handle that separately from
> the
> review of the locking chapters.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 06 Nov 2007 12:16:48 -0600

> words, nothing more to do.

Yes, I agree with the analysis.

Spencer