CTDB statd callout improvements - notably, add support for storing NFSv3 locking client data in the cluster filesystem

Add an option to allow NFSv3 locking client data from rpc.statd to be stored in the cluster filesystem. A previous version of this functionality was removed in commit 12cc8262 in 2010.

Why add it back?

  • The persistent_db method dequeues local files to a database during the monitor event, so can lose ~15s of data on a node crash.
  • The default method used by NFS-Ganesha for NFSv4 uses the cluster filesystem so, when that NFS server is in use, a dependency already exists.

This MR does:

  1. Rename a variable currently only used by (currently unsupported) nfs-ganesha-callout, and simplify a couple of things in that script.
  2. Fix some comments and some whitespace issues in statd_callout_helper.
  3. Improve some of the existing statd_callout_helper functionality for persistent_db.
  4. Factor out all of the persistent_db functionality into shell functions.
  5. Fix an impending race that will occur when support for shared_dir is added.
  6. Support CTDB_STATD_CALLOUT_SHARED_STORAGE=shared_dir.
  7. Update tests for above.
  8. Minor tweaks.

Checklist

  • Commits have Signed-off-by: with name/author being identical to the commit author
  • (optional) This MR is just one part towards a larger feature.
  • (optional, if backport required) Bugzilla bug filed and BUG: tag added
  • Test suite updated with functionality tests
  • Test suite updated with negative tests
  • Documentation updated
  • CI timeout is 3h or higher (see Settings/CICD/General pipelines/ Timeout)

Reviewer's checklist:

  • There is a test suite reasonably covering new functionality or modifications
  • Function naming, parameters, return values, types, etc., are consistent and according to README.Coding.md
  • This feature/change has adequate documentation added
  • No obvious mistakes in the code
Edited by Amitay Isaacs

Merge request reports

Loading