Subject: RE: [nfsv4] upcoming draft of RFC3530 errata

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Fri, 11 Mar 2005 10:54:35 -0500

Does the errata contain clarifications? If so, the use of the 
open_to_lockowner4 lockowner4 string could use some clarification.

The Linux server refuses to allow a client to ever use open_to_lockowner4 for 
a given lockowner string more than once, at least until they do a 
RELEASE_LOCKOWNER or a CLOSE that destroys the origional open stateid.

The AIX server allows re-use of the open_to_lockowner4 for a given lockowner 
string. RELEASE_LOCKOWNER releases all locks with the lockowner4 string.

thanks

-->Andy

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

---

From: Fredric Isaman <[email-masked]>
Date: Fri, 11 Mar 2005 13:58:49 -0500 (EST)

> open_to_lockowner4 lockowner4 string could use some clarification.

On a related note, there was the following discussion about a year ago.
It seemed to end with the decision that using open_to_lock_owner4 on a
previously established lock_owner is necessary.

However, I have a question regarding the final diagram quoted below.
It appears there are two different seqence numbers associated with the
LockOwner "P1".  Are these in fact two different lock_owners with
different sequence streams (which just happen to share the same name,
but can be distinguished by association with different opens), or are
they the same lock_owner for which the server needs to enforce a
single sequence number stream.

		       Fred

from Dave Noveck
> Note that (the spec) says, "In the case that the lock_owner is
> known to the server and has an established lock_seqid, the argument
> is just the lock_owner and lock_seqid".  In fact the argument, is the
> *lock_stateid* and lock_seqid.  My guess is that lock_stateid was
> substituted for lock_owner relatively late in the editing process with
> the idea that the lock_stateid gives you the right lock_owner.  The
> problem that this creates however is that you can have a situation in
> which the lock_owner is known to the server, but you still don't a
> lock_stateid for the approrpiate file/open_owner/lock_owner
> combination.  What do you do in this case?  It seems the only way
> you can get a lock_stateid when you don't have one is to do the
> open_to_lock_owner case of LOCK, which the text quoted above says
> you should only use if the lock_owner is not known to the server.
>
> It seems to me that there are two ways to resolve this.  You can just
> decide that the text about the use of open_to_lock_owner is wrong
> (as it is about what is in the exist_lock_owner4 case) and that you
> simply use the open_to_lock_owner4 case when you have to get a
> lock_stateid when you don't have one for the current open_stateid and
> lock_owner.  This would be my preference.
>
> An alternative is the vox spec vox dei approach which would simply
> decide that if the spec doesn't provide for a particular case, that
> case must somehow be foreclosed.  In that case, if a given lockowner
> needed to get a lock on a different file or a different open file for
> the same underlying fh, it would have to be represented by a different
> lockowner, so that the bad case of a known lock_owner with no =
> lock_stateid
> would not arise.
>
> The problem with this is that it is really not consonant with section
> 8.1.3 where the lock_owner concept is introduced

from rick
> P1 Opens files "a" and "b" with open_owner "P1"
> P1 forks off child P2
> 	P2 inherits Opens for "a" and "b"
> 	P2 wants to put locks on "a" and "b" for which it has inherited
> 		opens
> 	P2 locks "a" using open_stateid for P1's open of "a" to lock_owner
> 		"P2"
>
> The question seems to be what the client should do when P2 locks "b"?
> If I understand your response, it is expected to:
> 	P2 locks "b" using open_stateid for P1's open of "b" to lock_owner
> 		"P2"

>From Dave Noveck
> That's my interpretation of the way things should work but the way the
> spec is written it seems to say you can't do that.  Now it seems kind
> of arrogant to say flat out "The spec is wrong" but really that is what
> I think.

>From rick
> P1 Opens "a", getting StateidOa
> P1 Opens "b", getting StateidOb
> P1 Locks "a" with open_to_lock_owner using StateidOa, gets StateidL1
> P1 Locks "b" with open_to_lock_owner using StateidOb, gets StateidL2
>
> would result in a structure like:
>
> 		OpenOwner "P1"
> 		with open seqid#
> Open "a" <-StateidOa
> Open "b" <-StateidOb
> 				LockOwner "P1"
> 				seqid# N	<-StateidL1
> 						LockOwner "P1"
> 						seqid# L	<- StateidL2
>
> so the only distinction between the two LockOwner entries is the seq#
> and stateid reference. The first locks for "a" and "b" end up related to
> the LockOwner created at that point. Subsequent locks on "a" or "b" end up
> related to whichever LockOwner entry is referenced (as determined by which
> stateid is used) when the lock is created.
>
> For conflict checking, all the locks related to both these LockOwners are
> considered owned by "P1".