Subject: [nfsv4] yet more re: ReleaseLockOwner

From: [email-masked]
Date: Tue, 9 Sep 2003 11:32:51 -0400 (EDT)

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

Ok, I now think I know why you discussed this. I hadn't assumed that
LockOwner strings had only one entry in my hierarchy.
For example:

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". (Note that this is a logical structure and
not necessarily what might be used in an implementation. My implementation
actually keeps locks and opens hanging off of a structure referenced by FH
and the owners live in state structures referenced by the opens, locks, and
stateids.)

For the alternate client Op sequence of:
P1 Opens "a", getting StateidOa
P1 Opens "b", getting StateidOb
P1 Locks "a" with open_to_lock_owner using StateidOa, getting StateidL1
P1 Locks "b" with exist_lock_owner using StateidL1

would result in a structure like:

		OpenOwner "P1"
		with open seqid#
Open "a" <-StateidOa
Open "b" <-StateidOb
				LockOwner "P1"
				seqid# N	<-StateidL1

I think the question comes down to whether a Lock_stateid refers to:
- an <open_on_a_file/seq#/lock_owner>
OR
- a <seq#/lock_owner>
or, alternately, it can be stated as "Can the exist_lock_owner case be
used to lock a different file than the one that was locked when the
new Lock_stateid was first replied to the client".

At this point, the RFC seems to permit either Op sequence and either
interpretation of what a Lock_Stateid represents/can_be_used_for?

I guess my feeling is that, as a server writer, I should allow both cases
unless there is a clear statement otherwise.

Anyhow, is what I am concerned with clearer now (or murkier)? rick

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

---

From: Trond Myklebust <[email-masked]>
Date: 09 Sep 2003 11:53:35 -0400

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

     > or, alternately, it can be stated as "Can the exist_lock_owner
     > case be used to lock a different file than the one that was
     > locked when the new Lock_stateid was first replied to the
     > client".

The lock stateid can be used in READ and WRITE requests. That implies
that it needs to have an associated share access mode.

Furthermore, you have the CLOSE operation which must either free all
outstanding locks or return NFS4ERR_LOCKS_HELD. This too implies that
lock stateids are subordinate to the open state.

IOW the relationship has to be

   <open_on_a_file/seq#/lock_owner>

Cheers,
  Trond