Subject: Re: A few clarifications ...

From: Spencer Shepler <[email-masked]>
Date: Wed, 1 Aug 2001 15:54:40 -0500

On Tue, Ramesh Shankar wrote:
> >
> > > 3. Section 9.4.4 and section 9.5 (Page 84) are *totally* confusing.
> > > While it makes it appear in earlier sections (9.4.3, forexample) as if a
> > > client can continue to keep a file for which delegation has been opened
> > > by applying buffered opens and obtaining the correct stateids for use
> > > with READ/WRITE after the delegation is revoked, these sections seem to
> > > imply that such a case cannot be handled. I would assume that when a
> > > client loses delegation, it is to be interpreted to mean that the file
> > > is shared by other clients and it must not attempt to cache data for
> > > reading and writing without using cache validation techniques or
> > > explicit byte range locks.
> >
> > I think you're confusing delegation recall and revocation.
> >
> 
> After seeing the cryptic :-# remark by Brent, I found out that the terms 
> "recall" and "revocation" are used differently in the NFSv4 RFC. It 

Do by "differently" do you mean inconsistently within RFC3010?  In any
case, I will put an item on my list to make any necessary additions to
section 9.4 to clarify the usage of recall and revoke in the context
of delegations.

> would be useful if this is made more obvious than being hidden in some 
> para. Interestingly, the NetApp technical report TR3085 "The NFS Version 
> 4 protocol" (also available from the www.nfsv4.org) uses the term 
> "revoke" in the way the RFC uses the term "recall".
> 
> Thanks,
> 
> S.R.
> 

-- 

- Spencer -

---

From: Ramesh Shankar <[email-masked]>
Date: Wed, 01 Aug 2001 15:18:20 -0600

> section 9.4 to clarify the usage of recall and revoke in the context

Well I thought the terms "revoke" and "recall" have been used 
interchangeably in the RFC. Only when Brent pointed it out, did I find 
this difference hidden in one of the paras on pp. 72 (last para of 
section 9.2).

>> "revoke" in the way the RFC uses the term "recall".

The above paper was also partly responsible for my confusion :-)).

Thanks,

S.R.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 1 Aug 2001 17:43:26 -0500

On Mon, Ramesh Shankar wrote:

<...>

> 
> ------------------------------
> Mail #1:
> ---------------------------------
> 
> Hi Ramesh,
> 
> 
> > 1. Am I correct in understanding that while a delegation is granted to a
> > client at OPEN time, it is not automatically revoked when the client
> > performs a CLOSE? i.e. the delegation is revoked only in one of the
> > following ways:
> >  > - Client doesn't renew lease

This would result in the delegation being revoked.

> > - Server revokes lease and client finally makes a DELEGRETURN call.

As you have pointed out in other email, this should be that the server
"recalls" the delegation and the client returns it with DELEGRETURN.

> > - Client volutanrily surrenders lease using DELEGRETURN call.
> 
>  The protocol makes it clear that DELEGRETURN allows a client to
> end an delegation, though there is no mention of CLOSE returning
> a delegation.  I agree, some clarification required here.

Yes.  I agree.  Will add it to the list of todos.

> > 2. Related to the above. THere is a difference (I think) between NFS v4
> > delegation and CIFS oplocks. With NFS, since there is no per open
> > (stateful) file handle, client can buffer OPEN operations and then apply
> > them to the server at revocation time. However, CIFS uses stateful
> > handles and client cannot apply buffered open calls at lock 
> revocation time.
> 
>  Yes, I recall that there's a "Type 2" oplock that behaves differently.
> 
> > 4. Is NFS locking mandatory or advisory? This is really obscure in the
> > RFC. While it talks explicitly about mandatory locking and how the
> > stateids are useful in enforcing them, the following make it confusing:
> >  > - OPEN call returns information on whether mandatory locking is in 
> place
> > on the file. This is not clear. Is this supposed to mean whether someone
> > already has a mandatory lock on the file or is this the UNIX world "file
> > enabled for mandatory locking via the file permission bits overloading"
> > scheme? In case of the former, what if the file gets a mandatory lock by
> > another client *after* one client has already opened it. In the latter
> > case, what happens if the file is not enabled for mandatory locking?
> > - Wording on pp76 makes it appear as if what is used by NFS is really
> > advisory locking.
> >  > Any clarifications would be greatly appreciated.
> 
>  Locking is mandatory, though there are some "special" stateids
> for the benefit of UNIX users who are not used to being denied
> access this way.  There's been some discussion on the mailing
> list on this topic recently.

Yes. This is another area that needs to be clarified.  Will add it to
the list.

> Ramesh, I recommend you post these questions to the mailing list,
> [email-masked] so that the group as a whole can
> see your comments and discuss them.  In addition, document editor,
> Spencer Shepler, will read it too.
> 
> 	Cheers
> 		Brent
> --------------
> Mail #2:
> 
> Sorry to bug you Brent, but would appreciate if you could clarify this 
> point as well, which is not discussed in the RFC 3010 clearly.
> 
> OPEN takes nfs_lockowner and returns a stateid. This stateid serves as a 
> shorthand for the tuple <user, machine, process> represented by 
> nfs_lockowner. This is what must be passed to READ/WRITE. Will this 
> stateid be always returned by the server or will it be returned only 
> when a share mode restriction ( one of deny read, deny write, deny all) 
> is specified? Specifically, if I had OPENed the file with deny none, 
> will the server still give me a stateid?

Server will always return a stateid.

> LOCK (and so does UNLOCK!) takes a stateid and returns a stateid. Are 
> these supposed to be same? Can they be different? I am assuming that 
> once I do a LOCK, I have to use the state id returned by it for 
> READ/WRITE and not the one returned by OPEN. This is not mentioned 
> anywhere in the RFC BTW. If I do an unlock, then what happens? Which 
> stateid am I supposed to use now for subsequent READ/WRITEs performed 
> without holding any locks? The one returned by unlock? What if my server 
> supported partial byte range locks? Should I have to differentiate 
> between reading the locked range and unlocked range and send the correct 
> stateids? THere is some wording on the last para of pp 54 which kind of 
> gives some hints on how things are supposed to be, but it is a bit obscure.

The stateid represents the current, shared state between client and
server.  When a stateid is returned, the client is to use that stateid
for subsequent operations that require it as a parameter.  The state
discussions in the RFC will be updated and I will make sure to provide
the appropriate overview for this point.

-- 

- Spencer -