Subject: A few clarifications ...

From: Ramesh Shankar <[email-masked]>
Date: Mon, 30 Jul 2001 11:47:02 -0600

I sent the following questions to Brent Callaghan and he suggested that 
I post these in this news group.

He hasn't exactly elaborated on some of the questions and so any 
clarifications would be greatly appreciated.

While the answers to these questions maybe obvious to long time NFS 
implementors, it isn't obvious to a beginner like me!

Thanks,

S.R.

------------------------------
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
 > - Server revokes lease and client finally makes a DELEGRETURN call.
 > - 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.

 > 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.

 > 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.

 > 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.

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?

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.

---

From: Ramesh Shankar <[email-masked]>
Date: Tue, 31 Jul 2001 17:30:13 -0600

>  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 
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.