Subject: RE: [nfsv4] more re: ReleaseLockOwner

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 9 Sep 2003 09:32:52 -0700

> >> At this time, my server has a hierarchy of:
> >> OpenOwner
> >>	related Opens
> >>		related Lockowners
> >>			Locks (for that file opened by that OpenOwner)
> >
> >Hmmm.  Offhand I can't see why this (separate open_to_lock_owner4 for each
> >file) is troublesome.
> 
> Ok, so it sounds like you are in favour of the above relationship (which
> is what I've currently implemented). 

I'm reluctant to say "yes" since I can't say that I understand the 
implications of your hierarchy, so I'll just go on to your example.

> The good discussion I snipped all
> made sense to me. For the following scenarios:
>
> First scenario:
> 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"

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.

> which is what my current implementation handles, but it seems the RFC
> allows it to:
>	P2 locks "b" using the lock_stateid returned when it locked "a"

I don't think so.  It seems to me that if you do this you are saying
that the lock you are getting is associated with P1's open of "a",
which it isn't.  Now in this particular case, the server could see the
difference by looking at the current fh, but suppose we had opens of
"a" by P1 and by P3.  The association of the lock with the proper open
becomes semantically relevant when either of those open's is closed.
Semantically, a lock is associated with an lock_owner and an open file
and the only sensible way to make that association in the protocol is
to represent the open file by an open stateid and adding the lock_owner
information, which is exactly what the open-to-lock-owner case of LOCK
does.  The, the exist-lock-owner case is used to get new locks that have
the same lock_owner and open file combination.

> and the real question seems to be, is a client allowed to do this?

That is the question.

> [good stuff snipped]
> > 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.  

> I don't follow this. My understanding of a lock_stateid is that it is a
> shorthand reference for a lock_owner (Sec. 8.1.3) returned by a Lock Op,
> so how can there be a "known lock_owner with no lock_stateid"?

Hmmm.  That section does say:

   When the server grants the lock, it responds with a unique stateid.
   The stateid is used as a shorthand reference to the lock_owner, since
   the server will be maintaining the correspondence between them.

So to get real nit picky, it doesn't say that it is a shorhad reference
(and certainly not that it is only a shorthand reference) but that "it
is used as shorthand reference" which it is, but my sense of this is 
that it also serves as a shorthand reference to the associated open
file (i.e. and thence to the file and open owner).  And if it doesn't
have this information, how is one to know what the associated open 
file is? (and you need to know that).

[stuff on which we agree snipped]

> >> I'm now thinking the relationship is:
> >>			OpenOwner
> >>	related Opens			related LockOwners
> >> 					(ones that did open_to_lock_owner4
> >>					 using a stateid for any of the
> >>					 related Opens)
> >>						Locks (for all files that
> >>						       use this LockOwner)
>
> > It isn't clear from the above whether you are restricting each lock_owner
> > to locks for a given file, since you say above:

> Nope, I intended locks for all files to be hanging off the LockOwner
> that was associated with it either by the open_to_lock_owner4 having
> the lock owner string or the lock_stateid refering to the LockOwner.
> I also assumed "related LockOwners" will be a list of LockOwners, one
> for each lock owner string.
>
> For the above scenario:
> 		OpenOwner "P1"
> Open "a"
> Open "b"				LockOwner "P2"
> 						Lock "a"
>						Lock "b"
> 
> which could be constructed whether P2 does an open_to_lock_owner4 with
> lock string "P2" to lock "b" or an exist_lock_owner4 with the lock_stateid
> returned when locking "a". (The other hierarchy fails the
> exist_lock_owner4 case, since the lock_stateid refers to a lock_owner/lock
> for a different file.)
>
> As such, it seems more flexible. (Do you now see the difference?)

Yes, but what I don't understand is how you would deal with the case in 
which "a" was opened by P0 and "b" what opened by P1 and then P2 did the
same locks.

> >From your hierarchy, it isn't clear to me how you deal with the case
> >of the same file (same fh, that is), when there are two different opens
> >(different open_owner's, that is) and the same lock_owner tries to get
> >locks associated with both opens.  Does your client structure prohibit 
> >that.  What would your server do if 

> For my current server code (and I don't think this would change if I
> modify the code to what I was thinking of as hierarchy 2) it handles
> multiple Lock Ops via the same lock_owner using two
> open_to_lock_owner4s (even with different open_stateids for Opens of the 
> same file) the same as two Lock Ops on the same lock_stateid.
> (In other words, same lock_owner on same client, always
> allowed with the second one replacing the lock state left by the first
> for overlapping regions.) For both variants, the seqid#s should maintain
> the ordering to what the client chooses.

That sounds right to me.  It just doesn't seem that relationship between
open owners and lock owners is then hierarchical as it seems to be 
presented above.

> [more stuff snipped]
> Well, I think I understood your answer, but did I?

I think so, but that assumes I understood your answer :-)  We are
definitely approaching understanding (pehaps asymptotically).

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

---

From: Trond Myklebust <[email-masked]>
Date: 09 Sep 2003 13:00:39 -0400

>>>>> " " == Dave Noveck <Noveck> writes:

     > That sounds right to me.  It just doesn't seem that
     > relationship between open owners and lock owners is then
     > hierarchical as it seems to be presented above.

Isn't it correct, though, to say that the relationship between
open and lock stateids _is_ hierarchical?

IOW: The lock_owner and open_owners are both subordinate to a
clientid, but they are otherwise completely independent of one
another. I, the client, can mix and match open_owners and lock_owners
according to whim...

However once I've opened a file and are want to lock a byte range,
the lock stateid is instantiated as being subordinate to the open
stateid by means of the open_to_lock_owner4.
When I CLOSE the open_owner, I can no longer be holding any locks that
were created using those lock stateids that are subordinate to it.

Cheers,
  Trond