Subject: [nfsv4] re: re: more on open with claim_delegate_prev

From: [email-masked]
Date: Fri, 12 Dec 2003 11:12:54 -0500 (EST)

> Is that really true? 8.1.8 only states that a server cannot request an
> OPEN_CONFIRM as part of a reply to OPEN(CLAIM_DELEGATE_PREV).
> Presumably the reason for this is that the client must have issued a
> new SETCLIENTID call after the reboot, and so replay ambiguities are
> automatically resolved by the fact that the server will have sent it a
> new clientid?

I was referring to the para after the bullet points:
	These constraints are related in that reclaim-type opens are
	the only ones in which the server may be required to send a
	delegation. For CLAIM_NULL, sending the delegation is optional
	while for CLAIM_DELEGATE_CUR, no delegation is sent.

Since the second sentence doesn't list CLAIM_DELEGATE_PREV, that seems
to imply that it is in the "required" group. Admittedly, the first
sentence uses "may" instead of "must". I assumed that this was because
whether or not a delegation is returned depends upon the client's request
for CLAIM_PREV (in this case, a delegation "may" not be issued, but it is
not at the server's discretion).

Then in the 3rd para after the bullet points in 9.2.1:
	...consult stable storage so that the delegations can be reclaimed.
	For open delegations, such delegations are reclaimed using OPEN
	with a claim type of CLAIM_DELEGATE_PREV.

and the comment on pg 170
	/* Right to file based on a delegation granted to a previous boot
	 * instance of the client. File is specified by name.
	 */

To me, this seems to imply that the purpose of CLAIM_DELEGATE_PREV is to
reclaim those delegations. The comment also seems to suggest that the open is
based on the old delegation. If the old delegation doesn't still exist, does
it make sense for the open to succeed?

It seems to me that the client would want to know that the old delegation
state was lost, and I suppose that could be done in one of two ways:
- Return NFS4ERR_EXPIRED
OR
- Return NFS4_OK plus an Open with no delegation. (This just seems to me
  to be counter to the intent of the claim.)

> AFAICS, the only mention of a situation where the server is *required*
> to return a delegation is in the last paragraph on Page 174:
> 
>    The client should never assume that delegation will or will not be
>    granted in a particular instance.  It should always be prepared for
>    either case.  A partial exception is the reclaim (CLAIM_PREVIOUS)
>    case, in which a delegation type is claimed.  In this case,
>    delegation will always be granted, although the server may specify
>    an immediate recall in the delegation structure.

Yep, this suggests that returning an OPEN_DELEGATE_NONE for an open with
CLAIM_DELEGATE_PREV is acceptable.

So, anyone else have comments? rick

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

---

From: Trond Myklebust <[email-masked]>
Date: 12 Dec 2003 19:23:17 -0500

>>>>> " " == rick  <[email-masked]> writes:

     > To me, this seems to imply that the purpose of
     > CLAIM_DELEGATE_PREV is to reclaim those delegations. The
     > comment also seems to suggest that the open is based on the old
     > delegation. If the old delegation doesn't still exist, does it
     > make sense for the open to succeed?

Yes. The *purpose* of calling OPEN is to open the file. What would be
the point of requesting a delegation if you are not intending to use
it?

Delegations are an *optimization*. They are a means to an end, and not
an end in themselves...

Cheers,
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: 12 Dec 2003 19:51:36 -0500

>>>>> " " == Trond Myklebust <[email-masked]> writes:

     > Yes. The *purpose* of calling OPEN is to open the file. What
     > would be the point of requesting a delegation if you are not
     > intending to use it?

To clarify:

As I understand it, the main use of CLAIM_DELEGATE_PREV should be if a
client has a copy of the file in its local cachefs and wants to
revalidate that copy after it has rebooted. When OPENing the file, it
needs to ask the server whether it can still trust the contents of its
cachefs.

Cheers,
  Trond