Subject: RE: [nfsv4] re-acquiring delegations

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 21 Mar 2006 11:37:46 -0500

I'm also in favor of some mechanism for re-acquiring delegations,
agreeing with Dave Noveck below, in the S2 direction.

A callback for a delegation is probably overkill.  I can think of
other things I'd rather see new callbacks for, having to do with
applications making progress rather than clients making optimizations.

		Craig 

> -----Original Message-----
> From: Noveck, Dave 
> Sent: Tuesday, March 21, 2006 9:50 AM
> To: [email-masked]; Carl Burnett; [email-masked]
> Cc: [email-masked]
> Subject: RE: [nfsv4] re-acquiring delegations
> 
> I think we need at least a separate operation in order to get 
> a delegation, so I would say that S1 (do nothing) is not adequate.
> 
> One thing that would want on such an operation is separate 
> error codes to distinguish between a delegation being 
> unavailable due to a conflict or due to resources (client has 
> too many delegations).
> These are very different situations and the client probably 
> would want to do different things.
> 
> With regard to callbacks, I'm not sure whether we want/need 
> to go that far.  What you specify for S2 does not seem all 
> that onerous for the server (with an exception noted below).  
> I think the main issue will be whether clients are prepared 
> to use such a facility.
> 
> >  One of the reasons why a delegation can be recalled  is resoure 
> > limits on the server. And one of the  reasons why delegations might 
> > not be re-acquirable  is resource limits on the server. 
> Thus, it would  
> > nice if the server pushed the delegations the client  was 
> interested 
> > in.
> 
> I don't agree with callbacks to deal with this situation.  I 
> think once you go down this road, complexity starts to build.
> 
> In the case of resource limits, specific delegations should 
> not be recalled.  Instead RECALL_ANY should be used and the 
> client should give back the delegations that he thinks are 
> least needed.
> 
> The RECALL_ANY proposal suggest that if a client is reaching 
> the level at which delegations will be refused, we send a 
> RECALL_ANY so that he can give back delegations he doesn't 
> need so much and be granted new ones.
> 
> If resource allocations change, then I can see a callback to 
> notify the client.  Maybe this is a RECALL_ANY with a 
> resource limit beyond what you currently have.  The client 
> could then take that as a cue to try to get delegations that 
> were previously refused because of resource limits, using his 
> own current priorities.
> 
> The problem with sending priorities to the sever is that you 
> wind up needing to change them as circumstances change and 
> that winds up adding complexity.  So I would say that any 
> mechanism to give you callbacks when delegations are 
> available should only be designed to deal with the conflict 
> case and not the resource case.
> 
> 
> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]]
> Sent: Monday, March 20, 2006 5:46 PM
> To: Carl Burnett; [email-masked]
> Cc: [email-masked]
> Subject: Re: [nfsv4] re-acquiring delegations
> 
> 
> 
> 
> --- Carl Burnett <[email-masked]> wrote:
> 
> > Just a note that in my review of the early directory 
> delegation drafts I 
> > had proposed that it address the general notion of 
> requesting a delegation 
> > for an already opened file that lost its delegation due to a recall.
> > 
> > That suggestion was just for this case of re-obtaining a 
> delegation after 
> > a recall.
> 
> Thanks Carl.
> 
> Do you think my "S2" proposal is overkill, or would it suffice to
> have a separate client driven operation to allow a client to
> request a delegation on an already OPENed file?
> 
> (My S1 suggested just using OPEN to do this, but I the 
> problem that has
> over a separate GET_DELEG_FILE operation is that if the OPEN succeeds
> but fails to get an delegation, the client has to follow up 
> with a CLOSE).
> 
> Thus far in this discussion, only Carl and Spencer have voiced
> an opinion that we need to do something. I'd  be happy to write up
> a proposal for "S2" or anything else, but I'm not seeing a rough
> consensus. So it appears there's no overall desire to address this.
> 
> I will resolve the issue in the issues tracker (
> http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue2 )
> to say:
> 
>   No WG consensus to solve this issue
> 
> if I don't hear otherwise by Tuesday, March 21, 5pm pacific time.
> 
> 
> NFSv4.1 will recommend clients use 
> > 
> > Carl
> > 
> > 
> > Carl Burnett
> > AIX Kernel Architecture - Network File System
> > (512) 838-8498, TL 678-8498
> > (please reply to [email-masked])
> > 
> > 
> > Spencer Shepler <[email-masked]> wrote on 
> 03/14/2006 01:32:48 PM:
> > 
> > > On Tue, Mike Eisler wrote:
> > > > In NFSv4.0 a client can acquire a delegation and
> > > > have it recalled whenever there is contention on it,
> > > > or perhaps resource pressure on the NFSv4 server.
> > > > 
> > > > The only way to re-obtain a delegation is for the
> > > > client to re-open the file.
> > > > 
> > > > At Connectathon two weeks ago, someone reminded us
> > > > that this was something we wanted to address but
> > > > currently it is not covered in the NFSv4.1 i-d
> > > > or any associated i-ds.  Of course is this is a
> > > > significant last minute change to NFSv4.1.  I know
> > > > Brian Pawlowski, our co-chair, has been worried about
> > > > this issue, so perhaps there is a co-chair's privilege
> > > > rule that Spencer neglected to tell us about.
> > > > 
> > > > I've written down some thoughts. I haven't thought
> > > > about whether any it applies to layouts.
> > > > 
> > > > There are questions to be answered:
> > > > - do we want to do something in NFSv4.1 about this?
> > > > - what is the problem?
> > > > - what are the requirements?
> > > > - what are the solutions?
> > > > 
> > > > I'll leave it to the WG to reach consensus combined
> > > > with the rule of the co-chairs to answer the first
> > > > question. The rest I propose answers for here.
> > > 
> > > >From a personal perspective, this issue should be
> > > addressed in 4.1 given that we are adding directory
> > > delegations and I believe the next order issue will
> > > be a client that needs to do the simple task of
> > > obtaining a delegation for one previously held.
> > > 
> > > As WG co-chair, I am also in favor of this given
> > > the quality of specification issue; would like
> > > to have something that has a high probability of
> > > sticking.  Of course, this statement will likely
> > > come back to haunt me.
> > > 
> > > However, I reserve the right to change the above
> > > opinions if the eventual solution proves to be
> > > too complex with respect to "schedule".
> > > 
> > > Spencer
> > > 
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nfsv4
> > 
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> > 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: Carl Burnett <[email-masked]>
Date: Tue, 21 Mar 2006 12:41:08 -0600

My thoughts are similar to Craig and Dave's. A new op to ask for a 
delegation on an open file, or a general op to ask for a delegation on a 
file, dir, or symlink. Only the file case requires an open stateid.

As I think Mike suggested, it would be desirable if, for the case where 
the delegation can't be granted, the server can provide some detail as to 
why - contention, resources, capability not available, or delegation not 
supported for requested object type.

Carl

Carl Burnett

"Everhart, Craig" <[email-masked]> 
03/21/2006 10:37 AM

To
"Noveck, Dave" <[email-masked]>, <[email-masked]>, Carl 
Burnett/Austin/IBM@IBMUS, <[email-masked]>
cc
<[email-masked]>
Subject
RE: [nfsv4] re-acquiring delegations

                                 Craig

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 21 Mar 2006 15:56:51 -0600

> file, dir, or symlink. Only the file case requires an open stateid.

+1 for a separate operation in support of re-acquire.

> supported for requested object type.

and one more error: the server doesn't want to provide it (none of the above).
It may be that the server has other decisions being made that are not
represented in this list.

Spencer