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-9431 Lustre <p>Lustre has the ability to tune proc values using lctl conf_param on the MGS server. Those changes are stored and distributed to all the nodes avoiding to the complex process of setting ever node. The function class_process_proc_param() is used to change the setting using the lprocfs_vars that map to the proc file. With the move to sysfs/debugfs this no longer works. A new approach has to be written to handle sysfs settings. Also we should consider dropping setting debugfs entries since they tend to contain large quantities which the user will typical not set that kind of data</p> LU-9431

class_process_proc_param can't handle sysfs

Bug Major Resolved Fixed James A Simmons James A Simmons patch Tue, 2 May 2017 18:43:22 +0000 Sun, 1 Apr 2018 13:36:20 +0000 Sat, 3 Mar 2018 13:56:43 +0000 Lustre 2.10.0 Lustre 2.11.0 0 5 <p>There is already "<tt>lctl set_param -P</tt>" available for some time that replaces the "<tt>lctl conf_param</tt>" mechanism. The benefit is that "<tt>set_param -P</tt>" is using an upcall to <tt>lctl</tt> in userspace with parameter names the same as regular <tt>set_param</tt> is doing, unlike <tt>conf_param</tt> which parses these in a different manner internally and sets the parameters directly.</p> <p>The main drawback is that <tt>set_param -P</tt> has some issues that haven't been resolved since the patch was originally landed from Xyratex (<a href="https://jira.whamcloud.com/browse/LU-7183" title="lctl set_param -P does not work for sptlrpc flavor" class="issue-link" data-issue-key="LU-7183"><del>LU-7183</del></a> and <a href="https://jira.whamcloud.com/browse/LU-7004" title="fix &quot;lctl set_param -P&quot; to allow deprecation of &quot;lctl conf_param&quot;" class="issue-link" data-issue-key="LU-7004"><del>LU-7004</del></a> at least). As a result, we haven't been able to totally deprecate <tt>conf_param</tt>.</p> <p>As for debugfs parameters that have complex values for output, I can assure you that any of them which accept writes do not allow such complex values for input. In general, any writable parameters would allow clearing the counters that generate the output, or setting some limited tunable value. I don't think it makes sense to explicitly prevent writing to debugfs parameters beyond the existing case of making the parameter read-only if there is no write handler.</p> <p>Funny Oleg had the discussion with Greg about using lctl to set parameter which he didn't like. Yet looking at the upstream client this infrastructure is there. So you are suggesting we should instead fix set_param -P and truly deprecate conf_param. Question I have is do we have a list of where set_param -P is broken?</p> <p>There are several issues linked under <a href="https://jira.whamcloud.com/browse/LU-7004" title="fix &quot;lctl set_param -P&quot; to allow deprecation of &quot;lctl conf_param&quot;" class="issue-link" data-issue-key="LU-7004"><del>LU-7004</del></a> that show problems with "set_param -P", but of course there could be others. My suggestion is to change the scripts under <tt>lustre/tests</tt> to preferentially use <tt>lctl set_param -P</tt>, and only leave a few places that use <tt>lctl conf_param</tt> for compatibility testing. That way we can be sure that <tt>set_param -P</tt> is at least working well enough for all the existing regression tests.</p> <p>I see <tt>conf_param</tt> used in the following test scripts:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>lustre/tests/conf-sanity.sh:67 lustre/tests/test-framework.sh:12 lustre/tests/sanity.sh:9 lustre/tests/sanity-quota.sh:3 lustre/tests/ost-pools.sh:2 lustre/tests/sanityn.sh:2 </pre> </div></div> <p>James</p> <p>Is this something that you are intending to work on?</p> <p>Peter</p> <p>Based on the previous comments, it looks like this is a prerequisite for the sysfs changes to land. </p> <p>Yep. The current method for lctl conf_param only works for debugfs or proc but not sysfs. lctl set_parm -P will work with both. I just updated <a href="https://review.whamcloud.com/#/c/24031" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/24031</a> to test lctl set_param -P for the llite layer.</p> <p>ok - thanks James</p> <p>James Simmons (uja.ornl@yahoo.com) uploaded a new patch: <a href="https://review.whamcloud.com/30143" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/30143</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9431" title="class_process_proc_param can&#39;t handle sysfs" class="issue-link" data-issue-key="LU-9431"><del>LU-9431</del></a> obd: resolve config log sysfs issues<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 4145792fc0f91ec83debd3f613767ddecf490bc5</p> <p>I managed to lctl conf_param working with sysfs and debugfs. For the debugfs case for conf_param and in general for lctl set_param -P uevents are now being sent. In turn udev sees the event and acts on it based on the udev rules. By default we have:</p> <p>SUBSYSTEM=="lustre", ACTION=="change", ENV{PARAM}=="?*", RUN+="/usr/sbin/lctl set_param $env{PARAM}=$env{SETTING}"</p> <p>As you can see this approach allows a lot more flexibility. You can for example filter based on DEVPATH to only change variables on specific obd devices. Secondly this approach allows admins to run a different application or script instead of lctl. For example a admin might like to know if a tunable has been changed. Next an interesting feature that comes out of this is the ability to configure lustre with udev rules. For example we could do a</p> <p>SUBSYSTEM=="lustre", ACTION=="add", DEVPATH=="fs/lustre/osc/lustre-OST*", ATTR{max_dirty_mb}=64</p> <p>This opens up new possibilities here.</p> <p>Very interesting. I think this is a good way to implement the "set_param -P" functionality without having to use an upcall. We still need to fork/exec for each parameter, but that is no worse than the old upcall method. </p> <p>I assume we can just put a "lustre.conf" (or whatever) file in /etc/udev.d/ directory and this will work?</p> <p>I fixed the last remaining bug in this patch. Pleased review. Yes have a lustre.conf gile would work in /etc/udev.d to configure lustre.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/30143/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/30143/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9431" title="class_process_proc_param can&#39;t handle sysfs" class="issue-link" data-issue-key="LU-9431"><del>LU-9431</del></a> obd: resolve config log sysfs issues<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: a74b2b5bce71367506e59f1bdba163eb21235a29</p> <p>Landed for 2.11</p> Related LU-8066 LU-7004 LU-10869 LU-10756 Development Epic/Theme upstream Rank 1|hzzbo7: Rank (Obsolete) 9223372036854775807 Severity