Subject: [nfsv4] open_owner to lock_owner association

From: [email-masked]
Date: Mon, 5 May 2003 15:32:43 -0400 (EDT)

Ok, I'm still not clear on the relationship between an open_owner and
a lock_owner. Here's a couple of scenarios:
(I use "string" to refer to an open/lock owner and *string* to refer to
 the stateid returned by the server for the open/lock owner.)

- A client "C1" has processes which:
	"P1" opens file "a" with open_owner "C1:P1", receiving *C1:P1*
	"P1" forks off a child "P2"
		"P2" does a lock op on "a" with *C1:P1* and lock_owner
		"C1:P2", receiving *C1:P2* which is associated with "C1:P1"
	"P1" forks off a child "P3"
		"P3" does a lock op on "a" with *C1:P1* and lock_owner
		"C1:P3", receiving *C1:P3* which is associated with "C1:P1"

Now, does this associate both lock_owners "C1:P2" and "C1:P3" with
the open_owner "C1:P1"? (ie. one open_owner associated with several
lock_owners)

Does this imply that a close on open_owner *C1:P1* for file "a" must check for
locks on "a" owned by both "C1:P2" and "C1:P3"?

Now, here's another one:
- A client "C1" has processes which:
	"P1" opens file "a" with open_owner "C1:P1", receiving *C1:P1*
	"P1" forks off a child "P2"
		"P2" opens file "b" with open_owner "C1:P2", receiving *C1:P2*
		"P2" forks off a child "P3"
			"P3" does lock op on file "a" with *C1:P1*
			and lock_owner "C1:P3", receiving *C1:P3* which
			is associated with open_owner "C1:P1"
			"P3" does lock op on file "b" with *C1:P2* and
			lock_owner "C1:P3", receiving *C1:P3* prime, which
			is associated with both "C1:P1" and "C1:P2"

Now, does this associate lock_owner "C1:P3" with both the
open_owners "C1:P1" and "C1:P2"? (ie. one lock_owner associated with
multiple open_owners)

Here's another variation on the 2nd one:
- A client "C1" has processes which:
	"P1" opens file "a" with open_owner "C1:P1", receiving *C1:P1*
	"P1" forks off a child "P2"
		- "P2" opens "b" with open_owner "C1:P2", receiving *C1:P2*
		"P2" forks off a child "P3"
			"P3" does lock op on file "a" with *C1:P1*
			and lock_owner "C1:P3", receiving *C1:P3* which
			is associated with open_owner "C1:P1"
			"P3" does lock op on file "b" with existing lock_owner
			*C1:P3*, receiving *C1:P3* prime, which is
			associated with "C1:P1" which opened "a"

Is this case allowed? Or, is a lock op required to use a *open_owner* from
an open of the same file (or a *lock_owner* already aquired via an
*open_owner* from an open of the same file)?

So, does the above make sense or am I somewhere out in never never land?

It seems that understanding the relationship is also necessary in order
to figure out what open share/deny priviledges need to be checked for
read, write and setattr too. (I just recently realized that share/deny
access must be handled like mandatory locks and checked for read/write/setattr.)

Thanks for any help, rick
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 5 May 2003 13:26:23 -0700

>		"C1:P2", receiving *C1:P2* which is associated with "C1:P1"

The association is indirect.  What it is directly associated with
is *C1:P1*, the stateid for the open, and that open is associated 
with the open-owner "C1:P1"

> the open_owner "C1:P1"? (ie. one open_owner associated with several

Sort of but it is not the owners that are associated with one 
another but rather the stateid's that are associated with each
other.  Each of the stateid's is associated with a lockowner so
there is an indirect associated, but that isn't the primary thing.

So, for example *C1:P2* and *C1:P3* are associated with open stateid
*C1:P1*.  Now the owner of of *C1:P2* is "C1:P2" but the reverse
mapping from "C1:P2" to *C1:P2* is potentially one-many.  Can 
association between open-owners and lock-owners be inferred but it
is secondary.  The basic thing is the association of opens and locks. 

> locks on "a" owned by both "C1:P2" and "C1:P3"?

All locks associated with that open.  In your example, that is all
locks on "a" held by those two processes but it not be so.  If there
were different opens of "a" by two different processed, and P2 and P3
got locks from all of those, than a close of the open for the first 
process would only check for locks associated with that open, i.e.
that combination of file and open-owner.

> open_owners "C1:P1" and "C1:P2"? (ie. one lock_owner associated with

In your sense of association, yes.  But that association doesn't have
any consequences apart form the association between the lock stateids 
and the open stateid's.  Note that would would the same situtaion even 
if P2 opened "a" instead of "b".  It still would be a distinct open.

>			*C1:P3*, 

*C1:P3* isn't a lock-owner.  It's a stateid.  I don't understand your example.
If you do a lock specifying that stateid, you would be doing a lock on "a"
and not "b".  If the current file handle were for "b", you would get a 
BAD_STATEID error.

> receiving *C1:P3* prime, which is

> *open_owner* from an open of the same file)?

The state_id you specify is associated with the open of given file,
either directly in the case of one you got from open, or indirectly 
in the case you got from lock.  Your current fh must match that or
the server is going to be unhappy.

> access must be handled like mandatory locks and checked for read/write/setattr.)

For share-deny, the lock state-id's need to be mapped to the open state-id's
that they are associated with.  The open state-id's should be sufficient to
verify that the right processes are doing the right sort of IO.  Only if
you were doing mandatory byte-range locking would the lock-owners get into
the IO checking picture.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4