Whamcloud Community JIRA

Whamcloud Community JIRA https://jira.whamcloud.com This file is an XML representation of an issue en-us

9.4.14

940014

05-12-2023

[LU-3155] Permanent parameters with lctl set_param -P https://jira.whamcloud.com/browse/LU-3155 Lustre LU-3155

Permanent parameters with lctl set_param -P

Improvement Minor Resolved Fixed Emoly Liu Artem Blagodarenko patch Thu, 11 Apr 2013 07:45:11 +0000 Thu, 13 Aug 2015 19:10:05 +0000 Wed, 11 Sep 2013 01:33:01 +0000 Lustre 2.5.0 Lustre 2.5.0 0 11 Sorry, next information should be in issue's description. With this patch permanent and temporary formats are identical: Temporary: <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">set_param obdfilter.*.client_cache_seconds=15</pre> </div></div> Permanent: <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">set_param -P obdfilter.*.client_cache_seconds=15</pre> </div></div> 1. Permanent parameter is added to single special param log called "params". Same format is using. Command "param2", target "general" 2. Params log updates get pulled by all the clients and servers. Separate ldlm lock is used for that. 3. MGC executes via upcall-type mechanism to userspace a local lctl set_param string=value 4. The protocol can be extended for supporting another upcalls, not only lctl The command's format is next <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">#01 (224)marker 2 (flags=0x01, v2.3.63.0) general 'osc.*.max_dirty_mb' Wed Apr 10 23:32:13 2013- #02 (112)param2 0:general 1:osc.*.max_dirty_mb=64 2:lctl #03 (224)marker 2 (flags=0x02, v2.3.63.0) general 'osc.*.max_dirty_mb' Wed Apr 10 23:32:13 2013- </pre> </div></div> Benefits of using set_param -P instead of conf_param: 1. Identical format for permanent and temporary commands 2. wildcarding in strings 3. no unimplemented paths (e.g. ptlrpc services) 4. simpler implementation Please, change topic to "Permanent parameters with lctl set_param -P". Thanks. The patch is here: <a href="http://review.whamcloud.com/6025" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6025</a> Xyratex <a href="http://jira-nss.xy01.xyratex.com:8080/browse/MRP-272" class="external-link" target="_blank" rel="nofollow noopener">MRP-272</a> Emoly Could you please look after this one? Thanks Peter OK. Originally <a href="https://jira.whamcloud.com/browse/LU-2629" title="set_param and conf_param have different syntaxes" class="issue-link" data-issue-key="LU-2629"><del>LU-2629</del></a> Looking for some input from Intel architects. Alex Lyashkov see a scalability problem. This implementation shares a single llog over all targets and clients. Alex advizes splitting the configuration file into dedicated client and server versions. This save rpc's if only servers or clients are configured. Nathan Rutman believes that scalability is virtually the same as current conf_param code - items that affect the client llog will dominate the worst-case scenario anyhow. I.e. the difference between updating all clients, and all clients plus all servers, is minor. And the increased complexity of a) determining what items need to go into each log, and b) the additional code required is not worth the slight RPC savings. I haven't looked at the patch in detail yet, so my comments are only generalities. While I'm never fond of extra overhead imposed on e.g. the servers for something that should mostly impacts the client, I don't think this is a critical performance issue. The MGC llog processing on the OSS and MDS will be asynchronous, so will not affect server functionality, and the number of servers is small compared to the number of clients, so the load on the MGS should not be affected in any serious manner. I think Nathan brought up the critical issue which might force a single log for all tunables - the MGS has no way to know whether e.g. <tt>ldlm.namespaces.*.lru_size</tt> is a parameter for a client or a server. Any number of similar ambiguities exist that mean the parameters need to be stored in a single configuration llog. It is up to the administrator to specify any wildcards in a manner so that they apply only to the client or server, if appropriate. The nodes that process the parameters should ignore ones that do not apply locally. Can we get this landed please? I really would like to see a simpler and more robust configuration, and we don't want to diverge our branch from mainstream too far. The patch that Artem pushed is always hitting some test failures. After the patch passes the test and review, it will be landed. Test always fails on test_132 of sanity with message 'som is still disabled'. As I understand som is enabled on MGS and checked on MDS (this servers are on different hosts) and I can't find code that offer check this setting on MDS. Should this scheme works? Indeed, this test works on other branches. I can't understand why and how my patch blokes this. Bug is fixed. Waiting for testing results. I filed <a href="https://jira.whamcloud.com/browse/LUDOC-166" title="Document new "lctl set_param -P" option" class="issue-link" data-issue-key="LUDOC-166"><del>LUDOC-166</del></a> for tracking the required documentation update for this feature. It would be useful to have two additional patches for this change: <ul class="alternate" type="square"> <li>add deprecation warnings for "conf_param" usage for a future release (e.g. <tt>LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 53, 0)</tt>) and disable the code entirely in some future release (e.g. > 3.0.53)</li> <li>remove the use of "lctl conf_param" from test scripts around 2.7.53 (want to keep these for a while for interop testing)</li> </ul> patch <a href="http://review.whamcloud.com/6025" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/6025</a> landed for 2.5 I noticed that the original patch is also missing an update to the lustre/doc/lctl.8 man page. Warnings and man page <a href="http://review.whamcloud.com/7452" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7452</a> <a href="http://review.whamcloud.com/#/c/7436/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7436/</a> Artem, Please take a look at <a href="https://jira.whamcloud.com/browse/LU-3798" title="replay-single test_86: configuration log errors" class="issue-link" data-issue-key="LU-3798"><del>LU-3798</del></a> and comment. >Artem, Please take a look at <a href="https://jira.whamcloud.com/browse/LU-3798" title="replay-single test_86: configuration log errors" class="issue-link" data-issue-key="LU-3798"><del>LU-3798</del></a> and comment. Thanks. Done. Warnings and man page change landed for 2.5 Duplicate LU-2629 Related LU-3798 LUDOC-166 LU-7004 LU-3788 LU-3789 Development Rank 1|hzvnnz: Rank (Obsolete) 7649