Whamcloud - gitweb
LU-18357 ptlrpc: Use nodemap IAM for persisting filesets
Currently, two separate commands exist to set a fileset and both
behave differently. "lctl set_param (-P)" works as expected. On the
other hand, "lctl nodemap_set_fileset" updates the fileset only on the
local node and is not persistent. It could also be run from other
server nodes and not only from the MGS. This behavior is inconsistent
with other nodemap commands.
Ideally, we would want to use the nodemap IAM records for persisting
all nodemap properties without relying on secondary mechanisms, such
as the params llog which is currently used for filesets. This patch
adds support for persistence across restarts for "lctl
nodemap_set_fileset" commands. Filesets are split into 28 byte path
fragments which are stored alongside 4 byte fragment metadata into one
nodemap IAM record (which is 32 bytes).
For this, fileset fragments are stored in a "defined" subid range
within the NODEMAP_CLUSTER_IDX type. In anticipation of supporting
multiple filesets, the first fileset subid is reserved for a fileset
header. The subid range is set to support at maximum 256 nodemap
records for fileset fragments. 256 entries support enough fragments
to hold a PATH_MAX fileset in total. Only needed fragments are
inserted into the nodemap IAM.
To support seamless updates from fileset llog to IAM versions, a
nodemap flag was added which allows existing "lctl set_param -P
nodemap.<name>.fileset" to be applied outside the nodemap IAM as long
as no IAM records were set. Filesets from the llog are not migrated to
the IAM but are still compatbiel after an update. "lctl set_param
nodemap.<name>.fileset" is deprecated and uses the IAM once fileset
IAM records are in use.
Sanity-sec "test_27a" was modified to test fileset persistence.
Signed-off-by: Marc Vef <mvef@whamcloud.com>
Change-Id: Ic2e5e8026261867b7f0e90ea4ee2287251c503f7
Reviewed-on: https://review.whamcloud.com/c/fs/lustre-release/+/56757
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Sebastien Buisson <sbuisson@ddn.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>