Subject: [nfsv4] still more re: ReleaseLockOwner

From: [email-masked]
Date: Tue, 9 Sep 2003 14:38:10 -0400 (EDT)

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

Yikes, yes I see... For example:

P1 Opens "a" with OpenOwner "P1", gets StateidOa
forks P2 (which inherits open on "a")
P2 Opens "b" with OpenOwner "P2", gets StateidOb
forks P3 (which inherits opens for "a" and "b")
P3 Locks "a" with open_to_lock_owner using Stateid0a, getting StateidL1
	(and associates the LockOwner "P3"/StateidL1 with OpenOwner "P1")
P3 Locks "b" with exist_lock_owner StateidL1
	- this would associate the Lock for "b" with LockOwner "P3" and
	  OpenOwner "P1"

But the only Open for "b" is associated with OpenOwner "P2" and wouldn't
be in the same subtree of the hierarchy.

So, yes, I can't see how you can keep the Open<->Lock relationship without
a separate open_to_lock_owner being done for the first lock for each file.
(Yippee, I don't have to change my code after all:-)

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

Yes, I agree (especially now that you've convinced me I can't do both:-)
and in case it counts for anything, I vote for a separate open_to_lock_owner
for the first lock on each file, not just first lock for the lock_owner.

Thanks for all the feedback guys, rick
ps: I have this strange feeling I thought of the above case when I was
    coding this stuff last spring, but had forgotten about it.

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