[LU-17237] option for 'lctl list_param' to print parameter pathname

Related — Thu, 1 Feb 2024 22:19:15 +0000

For monitoring tools that are accessing a large number of parameters repeatedly, using the globbing of "lctl get_param" can generate a considerable number of incorrect pathnames for each lookup:

# strace -o /tmp/lctl-set_param.txt lctl set_param *.*.job_stats=Expire.500
mdt.myth-MDT0000.job_stats=Expire.500
error: set_param: setting /proc/fs/lustre/obdfilter/myth-OST0000/job_stats=Expire.500: Invalid argument
error: set_param: setting /proc/fs/lustre/obdfilter/myth-OST0001/job_stats=Expire.500: Invalid argument
error: set_param: setting /proc/fs/lustre/obdfilter/myth-OST0002/job_stats=Expire.500: Invalid argument
error: set_param: setting /proc/fs/lustre/obdfilter/myth-OST0003/job_stats=Expire.500: Invalid argument
error: set_param: setting /proc/fs/lustre/obdfilter/myth-OST0004/job_stats=Expire.500: Invalid argument
# grep -c ENOENT /tmp/lctl-set_param.txt
147

This is about 25 wrong pathname lookups for each of the 6 parameter files found in this case (though admittedly using a double wildcard is uncommon). Even for a single parameter there are 8 incorrect pathname lookups due to the globbing, which could be avoided.

There should be an option for "lctl list_param PARAMS" to print out the actual pathname(s) for PARAMS one time at startup, and then these pathnames could be accessed directly afterward. Perhaps "-P" and "--pathname" would be suitable.

The pathnames for most parameters will be constant for the lifetime of the running service, though software upgrades might potentially change them, so they shouldn't be saved into a file and should only be generated at runtime. Also, starting and stopping services on the local machine would change which parameter names are present on the local machine.

Whamcloud Community JIRA

[LU-17237] option for 'lctl list_param' to print parameter pathname