Subject: RE: [nfsv4] re-acquiring delegations

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 21 Mar 2006 09:50:10 -0500

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