Subject: [nfsv4] more re: ReleaseLockOwner

From: [email-masked]
Date: Mon, 8 Sep 2003 19:27:15 -0400 (EDT)

> out below.  But for now, as to your specific point, I don't think
> that whichever way you come down on this issue, you dispense with
> RELEASE_LOCKOWNER.  You can still have a an open file and have an
> unbounded set of different lock_owner's that get locks on that open
> file (not truly unbounded since there can only be 256 to the approx.
> four-billionth power different lock owner strings but that's 
> still a large number) so you may need a way to get rid of a 
> lock_owner when it will no longer be used even if you can get rid
> of the lockowner at close.

Yep, I never meant to say that a ReleaseLockOwner wasn't needed. I
was just interested in the implication of a server releasing an OpenOwner
on "associated" (whatever that means) LockOwners.

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

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

[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"?

>The problem with this is that it is really not consonant with section 
>8.1.3 where the lock_owner concept is introduced:
>
>   o  A variable length opaque array used to uniquely define the owner
>      of a lock managed by the client.
>
>      This may be a thread id, process id, or other unique value.    
>
>It would seem that a restriction that a given thread can only hold locks for
>a single file is fairly counter-intuitive in this context given what would
>normally expect a lock_owner to be (I guess politically it would be the extreme
>Levelers' locking model: Why should one lock_owner be allowed to have locks for
>multiple files when others don't? :-).  Also, if you had to create multiple 
>lock_owner's to represent a single process locking two different files, it would
>not be possible to find some very real deadlocks since thread A locking files
>X and Y and thread B locking files Y and X would appear as four different
>lock_owner's, and thus no deadlock is determinable.

Yes, I would agree that requiring a thread/process to use multiple
lock_owner strings doesn't seem reasonable.

>> 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?)

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

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

Thanks again for a good response, rick

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