Re: [nfsv4] Open_owner vs Lock_owner ?

[Trond Myklebust <trond.myklebust at fys.uio.no>]

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 ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4