nfsdcld - Man Page

nfsdcld [-d] [-F] [-p path] [-s stable storage dir]

nfsdcld is the NFSv4 client tracking daemon. It is not necessary to run this daemon on machines that are not acting as NFSv4 servers.

When a network partition is combined with a server reboot, there are edge conditions that can cause the server to grant lock reclaims when other clients have taken conflicting locks in the interim. A more detailed explanation of this issue is described in RFC 3530, section 8.6.3.

In order to prevent these problems, the server must track a small amount of per-client information on stable storage. This daemon provides the userspace piece of that functionality.

-d,  --debug

Enable debug level logging.

-F,  --foreground

Runs the daemon in the foreground and prints all output to stderr

-p path, --pipefsdir=path

Location of the rpc_pipefs filesystem. The default value is /var/lib/nfs/rpc_pipefs.

-s storage_dir, --storagedir=storage_dir

Directory where stable storage information should be kept. The default value is /var/lib/nfs/nfsdcld.

The following values are recognized in the [nfsdcld] section of the /etc/nfs.conf configuration file:

storagedir

Equivalent to -s/--storagedir.

debug

Setting "debug = 1" is equivalent to -d/--debug.

In addition, the following value is recognized from the [general] section:

pipefs-directory

Equivalent to -p/--pipefsdir.

The Linux kernel NFSv4 server has historically tracked this information on stable storage by manipulating information on the filesystem directly, in the directory to which /proc/fs/nfsd/nfsv4recoverydir points.

This changed with the original introduction of nfsdcld upcall in kernel version 3.4, which was later deprecated in favor of the nfsdcltrack(8) usermodehelper program, support for which was added in kernel version 3.8.  However, since the usermodehelper upcall does not work in containers, support for a new version of the nfsdcld upcall was added in kernel version 5.2.

This daemon requires a kernel that supports the nfsdcld upcall. On older kernels, if the legacy client name tracking code was in use, then the kernel would not create the pipe that nfsdcld uses to talk to the kernel.  On newer kernels, nfsd attempts to initialize client tracking in the following order:  First, the nfsdcld upcall.  Second, the nfsdcltrack usermodehelper upcall.  Finally, the legacy client tracking.

This daemon should be run as root, as the pipe that it uses to communicate with the kernel is only accessible by root. The daemon however does drop all superuser capabilities after starting. Because of this, the storagedir should be owned by root, and be readable and writable by owner.

The daemon now supports different upcall versions to allow the kernel to pass additional data to be stored in the on-disk database.  The kernel will query the supported upcall version from nfsdcld during client tracking initialization.  A restart of nfsd is not necessary after upgrading nfsdcld, however nfsd will not use a later upcall version until restart.  A restart of nfsd is necessary after downgrading nfsdcld, to ensure that nfsd does not use an upcall version that nfsdcld does not support. Additionally, a downgrade of nfsdcld requires the schema of the on-disk database to be downgraded as well.  That can be accomplished using the nfsdclddb(8) utility.

/var/lib/nfs/nfsdcld/main.sqlite

nfsdcltrack(8), nfsdclddb(8)

The nfsdcld daemon was developed by Jeff Layton <jlayton@redhat.com> with modifications from Scott Mayhew <smayhew@redhat.com>.

nfsdclddb(8).