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-7183 Lustre <p>Using <br/> lctl set_param -P lustre.srpc.flavor.default=skpi<br/> instead of:<br/> lctl conf_param lustre.srpc.flavor.default=skpi<br/> does not work correctly. No sptlrpc flavor is used. It appears that this may be because the llog for sptlrpc at MGS at CONFIGS/fsname-sptlrpc is not created. Instead with "set_param -P" the parameters are placed in params.</p> LU-7183

lctl set_param -P does not work for sptlrpc flavor

Bug Minor Closed Duplicate John Hammond Jeremy Filizetti SSK kerberos Fri, 18 Sep 2015 01:28:02 +0000 Mon, 26 Nov 2018 15:37:38 +0000 Sat, 21 Apr 2018 18:45:37 +0000 Lustre 2.9.0 0 10 <p>Linking to shared key though it will affect kerberos as well</p> <p>There are several other issues related to "lctl set_param -P" that will be fixed via <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> for 2.9.0. </p> <p>I did some debugging over the weekend and have traced it in failing to parse correctly in mgc_process_llog. Will continue to debug. I see the reason for lctl set_param -P failing as well. In mgs_parse_param() it reports:</p> <p>"setparam fs='general' device=general'</p> <p>This is wrong. Its just copying the device 'general' over to the file system name which causes the failure.</p> <p>I looked into why this is failing. The reason is because the way lctl set_param -P work is that is send a tunable setting to lctl in userland that than then sets the proc file entry. The problem for sptlrpc is that the flavor settings are not exposed in the procfs/sysfs tree.</p> <p>So normally for lctl set_param -P the config change is sent to lctl in userland so it can write to to the proc,sysfs, or debugfs file. In this case its a bit tricker than most since two pieces of data want to be written out. One is flavor i.e skpi etc and the other is the direction. Since set_param -P format follows $subsystem.$device.$param in this case we will have by default the source direction. This leaves us with the destination direction and the flavor needing to be set.</p> <p>Their are two ways we could handle this. First make srpc_info (debugfs or proc entry) writeable. This means pushing three values, the flavor, the destination direction, and the source net, o2ib1 for example, into srpc_info. Sadly source net is missing from srpc_info. One option is to push all the settings at the same time to srpc_info. The other option is create new individual files to handle each change in sysfs. In that case we run into making the change atomic. Any ideas?</p> <p>Hello James,</p> <p>Just what to remind that params config file has reserved field to store which means is used to execute configuration string. For example:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">#01 (224)marker   2 (flags=0x01, v2.8.55.0) general         <span class="code-quote">'ldlm.namespaces.*mdc*.lru_size'</span> Wed Nov 23 13:29:33 2016- #02 (128)set_param 0:general  1:ldlm.namespaces.*mdc*.lru_size=0  2:lctl   #03 (224)END   marker   2 (flags=0x02, v2.8.55.0) general         <span class="code-quote">'ldlm.namespaces.*mdc*.lru_size'</span> Wed Nov 23 13:29:33 201 </pre> </div></div> <p>Here "lctl" is stored in 2nd field which means configuration need to be execute using lctl set_param with given parameters. The original idea was to save the place to extend functionality and use any other method. But lctl set_param -P syntax need to be extended to store all permanent parameters in the same params file.</p> <p>I was looking for a way to set it with the upcall/udev event. So how failnode.nid is handled inspired me. We can use something like:</p> <p>lctl set_param osc.lustre-OST*.srpc_info="default=skpi".</p> <p>A patch should be coming shortly.</p> <p>New ticket replaces this work</p> Related LU-9567 LU-3289 LU-10937 LU-9399 Development End date Wed, 1 Jun 2016 01:28:02 +0000 Rank 1|hzxo27: Rank (Obsolete) 9223372036854775807 Severity Start date Fri, 18 Sep 2015 01:28:02 +0000