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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 9 Sep 2003 10:02:37 -0700

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

That was what was confusing me.

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

OK.  In my server there would be a single lock owner object with
two lock state objects sub-ordinate to it, but that's an implementation
detail.  The fundamental relationships are the same.

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

Right.

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

The former!!!!

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

And if so, how does the server know what open file is being referred to,
since the assumption that the open owner is the same will not work in all
cases?

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

I think we should come to an agreement about this and fix the spec
(whatever we decide) so that it is clear.  If you accept both than we
are going to have a situation is which there are multiple interpretations
of some basic concepts and interoperability testing becomes nightmarish:
client A and B work with server X and client B and C work with server Y.
Let's not go there.

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

Much clearer, but to get back to your initial remarks that started this
thread, the remaining lack of clarity is not any fault of yours but of
spec.  And I thought we proofread this thing fairly carefully.  Wrong!

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 9 Sep 2003 10:03:40 -0700

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

I certainly agree.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Tuesday, September 09, 2003 11:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] yet more re: ReleaseLockOwner

>>>>> " " == 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