Subject: [nfsv4] NFS client behavior on lock owner

From: <[email-masked]>
Date: Mon, 28 Apr 2014 13:49:17 -0500

Dell - Internal Use - Confidential
Hi,

I observed same behavior regarding lock owner from several NFS 4.0/4.1 clients from different OS, including CentOS, Fedora and Solaris. That is, when a range lock is outstanding, the lock owner will not be shared. Here is an example.

1.       Open file1

2.       Lock range 0-100

3.       Unlock range 0-10

4.       Open file2

5.       Lock range 0-100

The lock owners from 2 and 5 will be different even if a single process is opening the two files. If the unlock in 3 unlocks the full range 1-100, the lock owner in 2 will be same as in 5.

Is this true for all the NFS 4.0/4.1 clients? NFS spec doesn't seem to address it clearly. Can server implementation reply on this behavior?

Thanks,

Yanbei

---

From: Rick Macklem <[email-masked]>
Date: Mon, 28 Apr 2014 18:55:51 -0400 (EDT)

Yanbei Wang wrote:
> I observed same behavior regarding lock owner from several NFS
> 4.0/4.1 clients from different OS, including CentOS, Fedora and
> Solaris. That is, when a range lock is outstanding, the lock owner
> will not be shared. Here is an example.
> 
> 1. Open file1
> 
> 2. Lock range 0-100
> 
> 3. Unlock range 0-10
> 
> 4. Open file2
> 
> 5. Lock range 0-100
> 
> 
> 
> The lock owners from 2 and 5 will be different even if a single
> process is opening the two files. If the unlock in 3 unlocks the
> full range 1-100, the lock owner in 2 will be same as in 5.
> 
> 
> 
> Is this true for all the NFS 4.0/4.1 clients? NFS spec doesn’t seem
> to address it clearly. Can server implementation reply on this
> behavior?
> 
I believe the answer is "yes" for all of these questions.
The spec. didn't specifically allow multiple instances of any
particular lock_owner. By multiple instances, I am referring
to using the same lock_owner string again for the open_to_lock_owner
case of Lock, if the server might still have state for that
lock_owner string.

This means that a client cannot re-use the same lock_owner
string until there is no state (locks) related to that lock_owner
string and the client has done a ReleaseLockOwner operation
to ensure that the server no longer has the lock_owner string
in its state structure.

I ran into this late in the development cycle for the FreeBSD
client because most servers allowed multiple instances (related
to different open_stateids) of the same lock_owner string
and my client was doing that.
When I found out that not all servers allowed this (and it
was not specifically required to be supported), I fixed the
FreeBSD client by adding a FH to the lock_owner string (so
it refers to a process/file and not just a process) and by
doing explicit ReleaseLockOwner ops when the client is no
longer going to be using the lock_owner.

I suspect that, if you look at the case where you unlock the
entire range at 3, you will find a ReleaseLockOwner op being
done for the lock_owner between 3 and 5, so it can safely
use the same lock_owner string again.

All of this comes from one sentence in RFC3530's description
of Close, where it notes that the server must check for
"associated locks". After some time, it became apparent that
this association can only be established by the open_to_lock_owner
case of Lock and that means that this case must be used for
4, since it is using a different open_stateid for a different
file (file2).

This took quite a while to resolve during interoperability
testing and I'll admit I've never looked at rfc3530bis, to
see how it is described there.

Now I'll see if anyone disagrees with my view of this, rick
ps: I can at least tell you that the answer is "yes" for the
    FreeBSD client.

> 
> 
> Thanks,
> 
> 
> 
> Yanbei
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>