Notes on Linux's /proc/locks and NFS v4 locks as of Ubuntu 22.04

July 10, 2023

Now that I've tried out NFS v4 on Ubuntu 22.04, I have some additional notes on NFS v4 locks and /proc/locks, to go with my earlier notes on NFS (v3) locks. It turns out that there are some changes from NFS v3 to NFS v4, at least on your NFS server.

Here is what an exclusive POSIX lock looks like on an Ubuntu 22.04 NFS v4 server:

4: POSIX  ADVISORY  WRITE 704 fc:02:669294 0 EOF
5: DELEG  ACTIVE    READ 704 fc:02:669294 0 EOF

The equivalent information from lslocks is:

nfsd    704 DELEG   READ  0     0   0 /...
nfsd    704 POSIX   WRITE 0     0   0 /...

There are two obvious differences in this. First, the process ID owning the lock is for one of your nfsd processes, not lockd. This is likely because in NFS v4, locking is integrated into the NFS protocol instead of being an additional set of protocols with separate daemons. The second is that there is this strange 'DELEG ACTIVE' (pseudo-)lock. I believe that this is a NFS v4 read delegation, where the server promises the client that it will be notified before anyone else is allowed to write to the file. Read delegations (usually) appear when a file is opened on the NFS client, not just when you take a lock, but since Unix locking works on file descriptors, you necessarily have to have an open file before you can get a lock. These delegations may linger after the relevant process on the NFS client has closed the file in question.

(Looking at the source code, it appears that a 'LEASE' type is also possible in general, although I don't know if it appears in NFS v4. The 'ACTIVE' status can also be 'BREAKING' or 'BREAKER'. All of this is in the kernel's lock_get_status() in fs/locks.c.)

The process ID may be less predictable than it is for NFS v3 locks, since there are generally multiple nfsd processes and I'm not sure if there is any consistency about which one becomes the owner of any particular lock. You may need to check against every nfsd process ID if you want to identify NFS v4 server locks.

Although I'm not completely sure what's going on in NFS v4, getting a shared lock on a file opened for reading with with either fcntl() or flock() produces no visible POSIX lock on the NFS v4 server, just a DELEG READ entry. If you open the file for writing and then take s shared lock, you do get a POSIX lock visible on the NFS server. The shared lock still works (ie, it prevents an exclusive lock from being acquired), so something is going on.

Unlike the situation with NFS v3 locks, where you have to dig into the kernel data structures to find the client who owns a lock, it appears that the NFS v4 server directly exposes this information in files under /proc/fs/nfsd. Based on casual inspection, 'clients/<id>/states' appears to contain information on delegations and locks from that client, while 'clients/<id>/info' identifies the client. Actual locks in the 'states' file are 'type: lock', as opposed to the other types (which may appear in quantity, due to delegations).

(A number of states show up in the 'states' file and I don't know enough about NFS v4 right now to understand them, or how the states change as you do various things.)

Comments on this page:

From at 2023-07-11 10:44:56:

(A number of states show up in the 'states' file and I don't know enough about NFS v4 right now to understand them, or how the states change as you do various things.)

I think most of them just reflect open files – where NFSv3 mostly operated on stateless file handles, NFSv4 has stateful open() and close() like many other network filesystems do. If a client calls open("/net/sanfoo/bar"), it'll show up among states on the server as an 'open' state (plus apparently a 'deleg' state) even without the client issuing any reads or writes.

The "deny: --" in the 'state' file appears to be part of "share reservations", which smells very much like the inverse of MS-DOS FILE_SHARE_* flags that SMB also has. (Some things were "imported" to NFSv4 from Windows and SMB, e.g. NFSv4 ACLs in particular (not supported by Linux but present in FreeBSD and ZFS) are almost a direct copy of WinNT/SMB/NTFS ACLs, which themselves are a mirror copy of OpenVMS ACLs. Talk about Unix heritage...)

Written on 10 July 2023.
« Polymorphism and other important aspects of inheritance
How I move URLs between browsers in my Unix desktop environment »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jul 10 22:42:35 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.