Subject: Re: [nfsv4] re-acquiring delegations

From: Mike Eisler <[email-masked]>
Date: Fri, 7 Apr 2006 00:47:35 -0700 (PDT)

--- Spencer Shepler <[email-masked]> wrote:

> On Tue, Carl Burnett wrote:
> > 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.
> 
> +1 for a separate operation in support of re-acquire.
> 
> > 
> > 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.
> 
> 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.

Based on feedback from Dave Noveck, Carl Burnett, and
Trond Myklebust, I now present proposed solution S3 for the
problem of re-acquiring recalled delegations (and layouts).

The idea is that at the time a delegation is requested
(OPEN, GET_DIR_DELEGATION, LAYOUTGET), the client indicates
if it was callback signalling of the recallable object
being available if the object cannot be granted.

The typical flow is:

	do OPEN, GET_DIR_DELEGATION, LAYOUTGET, WANT_DELEG
		(for regular files and all other file
		types except directories)

	if we got the recallable object, use it.

	else if get didn't get the recallable object, if we indicated
		we want a callback when the object is
		available, the server tells us if it will
		send a callback later

		if we aren't going to get a callback then
			set a timer on the client, and
			when it fires, do

				GET_DIR_DELEGATION, LAYOUTGET, WANT_DELEG

		else we are going to get a callback,
			so record a stateid for the
			pending delegation or callback
			and do something else

	There are two types of callbacks:

	1. a push to give
	   us the delegation. This is used for regular files when
	   we have contention for the file (read vs. write vs write
	   conflicts). 

	2. a signal to tell us how many recallable objects
		of the specified type we can have (inverse of
		RECALL_ANY). This is used for all recallable
		objects, including layouts.

The client can implement as much of this as it wants.

The server can implement WANT_DELEG if it wants. The server
can also implement push or signal or both if it wants. 

While I was add it, since re-acquiring delegations on
regular files should be done by path name, I enhanced OPEN to
permit OPEN by file handle in the all 4 CLAIM types. The re-acquire
delegation and OPEN operations share some arguments so this
made sense to me.

More details in:

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/file5/deleg2.txt

Comments welcome.

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

---

From: Mike Eisler <[email-masked]>
Date: Thu, 13 Apr 2006 22:42:07 -0700 (PDT)

> problem of re-acquiring recalled delegations (and layouts).

I haven't had any feedback. I'll proceed with sending Spencer edits.