Subject: [nfsv4] re: re: yet more on ReleaseLockOwner

From: [email-masked]
Date: Tue, 9 Sep 2003 12:42:15 -0400 (EDT)

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

Interesting you should mention this. I've always thought it a bit weird
that the stateid can either be from an Open or a LockOp, but I can live
with it.

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

I would say it implies a relationship, but not necessarily subordinate.

> 
> IOW the relationship has to be
> 
>    <open_on_a_file/seq#/lock_owner>

That's fine with me (it's what my server code currently implements), but
given the hierarchy:

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

I would simply say that the "associated Open" (which holds the share/deny bits)
is the Open for the correct file ("a" or "b" as indicated by the CFH for Read,
Write or Setattr) off the same OpenOwner. (You only need one Open
for each file for each OpenOwner, so that isn't ambiguous.)
For Close, you simply go over
and check for locks on all the LockOwners off the same OpenOwner.

Seems to me the required association exists? rick

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