Installation checker

[brettkettering]

We want some way to check installations to ensure that they are correct. I have attached a hand-drawn representation of the Multi-Component file systems structures used to implement MC MarFS.

This checker will need to know what the configuration is. Check the environment variable MARFSCONFIGRC or /etc//marfs/marfsconfigrc, in that order. Read the configuration with libmarfs functions.

The check needs to be done on all nodes used to do transfers to and from MC MarFS. So, one could write a MPI program that does:

1. read config
2. for each repo, we get the path template, a sprintf-like thing
3. need a path to each mount point, expanded from template
4. stat mount points
5. readdir each

Namespace permissions vary. Printout what they are so the Admin can see them.

Each namespace needs to be its own GPFS file set. Look at the Garbage Collector for how to get these.

If not in PATH, define MARFSCONFIGEX -> On Batch FTAs only points at marfs_config executable.

BATCHFTAS must be defined on Interactive FTAs.

Verify pipetool_remote exists with "which" on Batch FTAs.

Verify pipetool exists with "which" on Interactive FTAs.

Verify PFTool script that limits commands that can be executed exists. Talk to Chris DeJager about where this should be.

PA2X header file that has to be in a certain place because it's hard-coded into PA2X code. Ask Jeff Inman about this.

MC_File_System_Structures-170613.pdf

[jti-lanl]

TBD:

• Regarding namespace permissions, marfs_config should print them out as a list of strings, rather than just show the bit-mask.

• marfs_config should show the "generic" per-DAL config options. I think those must've been introduced after marfs_config.

• Currently, path-expansion happens in two phases. After the first phase (mc_update_path on the template from the config), all that needs substituting-in during the second phase is the block-number. This could be done programmatically, by looking at the MC DAL config options (see previous item). One could then generate all the per-block paths.

  After we pivot to RDMA code, the path-template expansion (for RDMA and for MC) is done by a per-DAL snprintf function. Formerly, this snprintf was internal to libne functions. I'm not saying we must go straight to this for Brett's issue, but filling out the template in the case of RDMA paths is a little more complex, and more-likely requires access to the per-DAL config options.

  When we get to RDMA repos, there is also test_client which allows you to interact with server(s) on each individual storage node, using a generic path-template. If you know the name of an object-file on a given server, you can use the "template" file on the command line. It supports a stat function, but we could add something else, if needed.