https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-17343 Lustre <p>The "<tt>lctl get_param</tt>" and "<tt>lctl list_param</tt>" commands allow resolving and dumping Lustre parameters and statistics in a simple manner, as it handles the internal details of where the parameters are stored. </p> <p>Due to ongoing changes in the kernel policies on where parameters are located, the actual pathname of a parameter/stats file may change by kernel and Lustre release. Originally, parameters were all under "<tt>/proc/fs/lustre</tt>" and "<tt>/proc/net/lnet</tt>", but then "<tt>/proc</tt>" usage was deprecated so many parameters moved to "<tt>/sys/fs/lustre</tt>", but this is constrained to being simple "<tt>name=value</tt>" pairs, and "complex" (multi-value, multi-line) parameters were moved to "<tt>/sys/kernel/debug/lustre</tt>" and "<tt>/sys/kernel/debug/lnet</tt>". Unfortunately, the kernel changed the access policy for "<tt>/sys/kernel/debug</tt>" to be accessible only to the <tt>root</tt> user, and as such any data collection tools must also run as root in order to access these statistics, until such a time we create our own "<tt>lprocfs</tt>" to hold statistics and allow them to be accessed by non-root users.</p> <p>In the meantime, for tools that monitor Lustre statistics, it is desirable to avoid the overhead of "<tt>lctl get_param</tt>" trying to do multiple pathname resolutions each time a parameter is accessed, which might be once per second or more. This drives the tools to hard-code the direct parameter pathnames into the tool instead of using "<tt>lctl get_param</tt>" to access the parameters, which is fragile and may break between releases.</p> <p>It is desirable to have a mechanism to "resolve" parameter/stats pathnames for the currently-running Lustre version so that they can be used directly, without hard coding them. To do this, it would be useful to have an option "<tt>lctl get_param <span class="error">&#91;-p|--path&#93;</span> PARAM</tt>" and "<tt>lctl list_param <span class="error">&#91;-p|--path&#93;</span> PARAM</tt>" that prints the actual pathname(s) for <tt>PARAM</tt> instead of the value.</p> <p>There is already a function "<tt>llapi_param_get_paths()</tt>" that is available to resolve the parameter name to one or more pathnames, but it needs the "<tt><span class="error">&#91;-p|--path&#93;</span></tt>" option implemented to allow printing these pathnames to stdout for use by the monitoring tools.</p> LU-17343

mechanism to resolve 'lctl get_param' parameters to pathnames

Improvement Minor Open Unresolved WC Triage Andreas Dilger easy Thu, 7 Dec 2023 18:22:23 +0000 Mon, 29 Jan 2024 19:04:09 +0000 Lustre 2.16.0 0 6 <p>I think it would be a relatively simple change to the <tt>lctl</tt> tool - basically just adding the parsing of the "<tt><span class="error">&#91;-p|--path&#93;</span></tt>" option that works mostly like "<tt>lctl get_param &#45;N</tt>" and "<tt>lctl list_param</tt>", but having it print the <b>pathname</b> <tt>paths.gl_pathv<span class="error">&#91;i&#93;</span></tt> of the parameters directly instead of calling <tt>display_name()</tt> to convert the parameters to the dot-separated format.</p> <p>There are some cleanups in the code that should be done, like rename "<tt>po_only_path</tt>" and "<tt>po_show_path</tt>" to be "<tt>po_only_name</tt>" and "<tt>po_show_name</tt>" and add a new "<tt>po_only_pathname</tt>" (so it doesn't get confused with the old "<tt>po_only/show_path</tt>"). Similarly, a new <tt>LIST_PATHNAME</tt> should be added to <tt>enum parameter_operation</tt> to differentiate this from <tt>LIST_PARAM</tt>.</p> <p>Our tools never get love <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> The plan for stats is to implement an Netlink / libyaml approach to allow non-root to get stats. That doesn't have a path in the classic sense. I have something kind of working that I can push.</p> <p>This would be very useful for us.</p> <p>A long time ago when we wrote our tools, we looked at strace and the code and saw lctl was just doing it's own path resolution to open these files anyway, so we now just skip all of that and try to dynamically find the "proc" files directly outside of lctl. </p> <p>Being able to do "lctl list_param -p -R ..." and some caching + simple path heuristics would mean a lot less evil /proc and /sys path like calls would certainly save some CPU time and be a lot less messy.</p> <blockquote> <p>The plan for stats is to implement an Netlink / libyaml approach to allow non-root to get stats. That doesn't have a path in the classic sense. I have something kind of working that I can push.</p></blockquote> <p>I think that is a much bigger pill than most developers are willing to swallow. That requires adding a huge amount of complexity to the tools to manage Netlink and YAML, instead of "open/read". I think this change to dynamically discover the pathnames on the currently running system would be fairly easy to implement (either as an installation step to run a script and generate a config file that holds the pathnames for the stats files), or as a few-line change to run "<tt>lctl list_param -p <em>PARAM</em></tt>" to generate the pathname at runtime instead of hard-coding the absolute pathname into the binary.</p> Related Development Rank 1|i04493: Rank (Obsolete) 9223372036854775807 Severity