Subject: Re: [nfsv4] lockowner expiry

From: [email-masked]
Date: Thu, 6 Jul 2006 17:51:07 -0400 (EDT)

[stuff snipped for brevity]
> E.g. it allows this sequence of operations, all on the same file:
> 
> 	open("openowner1") -> openstate1
> 	lock(openstate1, "lockowner1", seqid = 0) -> (openstate2, lockstate1)
> 	lock(openstate2, "lockowner1", seqid = 0) -> (openstate3, lockstate2)
> 
> and then you can do further locks with lockstate1 and lockstate2, and
> the two will have independent stateid streams.

Last para of Sec. 14.2.10:
   The locker argument specifies the lock_owner that is associated with
   the LOCK request.  The locker4 structure is a switched union that
   indicates whether the lock_owner is known to the server or if the
   lock_owner is new to the server.  In the case that the lock_owner is
   known to the server and has an established lock_seqid, the argument
   is just the lock_owner and lock_seqid.  In the case that the
   lock_owner is not known to the server, the argument contains not only
   the lock_owner and lock_seqid but also the open_stateid and
   open_seqid.  The new lock_owner case covers the very first lock done
   by the lock_owner and offers a method to use the established state of
   the open_stateid to transition to the use of the lock_owner.

Now, to me the above seems to say that your case isn't what was intended,
although I suppose it comes down to your interpretation of what "known
to the server" actually means.

I believe that the server shouldn't release a lock_stateid until the
associated open is closed unless it receives a ReleaseLockOwner, since the
above implies to me that
open_to_lock_owner4 is only used by the client to acquire the lock_stateid.
Since I see no mention of a client being expected to do the open_to_lock_owner4
again if a certain error is recieved from the server, I believe that premature
release of the lock_stateid at the server should not be a part of its normal
operation.

As to whether the above forbids re-use of open_to_lock_owner4 per your
example, your guess is as good as mine.

I can say that my client wouldn't do the above example and doesn't expect
use of a lock_stateid to stop working before it does a close on the
associated open.

rick

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