Rick writes:
The open_to_lock_owner case also establishes the initial seqid#
for the new
lock_stateid, using the seqid# of the open_stateid, so
serialization of
lock ops can be guaranteed.
BTW: This raises a point that proved contentious at Connectathon
'08, so
I'd like to raise it to the IETF working group. The question is as
follows:
Does the above seqid and serialisation apply to all
future locks that are taken using this lock_owner, or
does it apply only to all future locks that are taken
using this lock stateid?
I'd argue that the seqid follows the lock stateid, but some of the
attendees at Connectathon were asserting that you should serialise all
locks that use a given lock_owner, even if those locks are being
applied
to different files.
So far, it would seem as though Rick's v4 client is the only one
that is
likely to be affected, since both Linux and apparently Solaris create
lock_owners that are unique per <open_owner,file>.
Cheers
Trond
----------------------------------------------------------------------
------
On Thu, 2008-06-26 at 10:47 -0400, Rick Macklem wrote:
I now have a few question about locks/lock_owners and the related
states
within a NFSv4 server.
As far as I have understood, the first time a lock_owner creates
a lock
using OP_LOCK4, it must use an open_owner that has a state on the
related file. It seems to me that the open_owner and the
lock_owner will
be different entities with different name and resources. Does
this mean
that a lock_owner cannot own a share reservation. I believe that
in this
case, I should return a severe error. Is this true ? Which error
code
should I return ?
The lock_owner is a different entity, but can have the same name
as an
open_owner and often does. For example, in my client, the open_owner
granularity is the posix process, so when a posix process opens a
file
and then does byte range locks on it, the open_owner name and
lock_owner
name are the same (but the open_to_lock_owner case creates a separate
entity for byte range locks, referenced by the lock_stateid
returned in
the reply). The open_to_lock_owner case also establishes the byte
range
locks related to the open_stateid used (which means that, upon
close of
the open_stateid, if any of these locks exist, you must unlock
them or
return NFS4ERR_LOCKS_HELD).
It is also possible for a client to do the open_to_lock_owner case
multiple
times with the same lock_owner name, but a different open_stateid,
when doing
byte range locking on multiple files (or multiple opens of the
same file,
but with different open_owners, such as an open inherited from a
parent
process).
Essentially, a lock_owner refers to whatever the client wants lock
conflicts
to be checked against: different lock_owner-->potentially
conflicting lock.
(In a posix client, this would normally be a name that refers to a
posix
process, since locking within a process never conflicts.)
The open_to_lock_owner case also establishes the initial seqid#
for the new
lock_stateid, using the seqid# of the open_stateid, so
serialization of
lock ops can be guaranteed.
Hope this helps, rick
_______________________________________________
NFSv4 mailing list
NFSv4 at linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
_______________________________________________
NFSv4 mailing list
NFSv4 at linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4