<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 03:31:11 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-16931] add lctl mechanism (list_param?) to report changes to tunable parameters</title>
                <link>https://jira.whamcloud.com/browse/LU-16931</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;It would be useful to have a generic mechanism that reports when tunable parameters are modified.  For example with &quot;&lt;tt&gt;lctl list_param -FR &apos;&amp;#42;&apos;&lt;/tt&gt;&quot; it will print whether the entry is a directory and if the parameter is &lt;em&gt;writable&lt;/em&gt; with trailing &quot;&lt;tt&gt;/=&lt;/tt&gt;&quot;:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;$ lctl list_param -FR &apos;*&apos;
:
jobid_name=
jobid_this_session=
jobid_var=
lbug_on_eviction=
ldlm/
ldlm.cancel_unused_locks_before_replay=
ldlm.namespaces/
ldlm.namespaces.MGC192.168.20.1@tcp/
ldlm.namespaces.MGC192.168.20.1@tcp.dirty_age_limit=
ldlm.namespaces.MGC192.168.20.1@tcp.early_lock_cancel=
ldlm.namespaces.MGC192.168.20.1@tcp.lock_count
:
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Firstly, being able to list only &lt;b&gt;writeable&lt;/b&gt; parameters with &quot;&lt;tt&gt;lctl list_param -w &lt;em&gt;PATTERN&lt;/em&gt;&lt;/tt&gt;&quot; would be useful for separating tunables from read-only parameters.&lt;/p&gt;

&lt;p&gt;Secondly, and more importantly, being able to easily find/report parameters that were actually &lt;b&gt;modified&lt;/b&gt; on the client or server for whatever reason (either from saved parameters on the MGS or manually with &quot;&lt;tt&gt;lctl set_param&lt;/tt&gt;&quot;) would make debugging system configuration issues much easier.&lt;/p&gt;

&lt;p&gt;One limitation is that these parameters are exposed to userspace via &lt;tt&gt;/proc&lt;/tt&gt; and &lt;tt&gt;/sys&lt;/tt&gt; files, so just storing an internal flag for the modified parameter itself does not give us any way to report them directly to userspace.&lt;/p&gt;

&lt;p&gt;One option would be to change the mtime of the parameter inode when it is modified?  This might make it possible to distinguish those parameters that have a different mtime from the ctime.  Currently they are always the same:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# find /{proc,sys}/fs/lustre /sys/kernel/debug/lustre -type f | grep lru_size | xargs ls -lc
-rw-r--r--. 1 root root 4096 Mar  9 11:33 /sys/fs/lustre/ldlm/namespaces/MGC192.168.20.1@tcp/lru_size
-rw-r--r--. 1 root root 4096 Apr 16 02:09 /sys/fs/lustre/ldlm/namespaces/myth-MDT0000-mdc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:31 /sys/fs/lustre/ldlm/namespaces/myth-OST0000-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Apr 16 02:09 /sys/fs/lustre/ldlm/namespaces/myth-OST0001-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:32 /sys/fs/lustre/ldlm/namespaces/myth-OST0002-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:32 /sys/fs/lustre/ldlm/namespaces/myth-OST0003-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:31 /sys/fs/lustre/ldlm/namespaces/myth-OST0004-osc-ffff979380fc1800/lru_size
# find /{proc,sys}/fs/lustre /sys/kernel/debug/lustre -type f | grep lru_size | xargs ls -lu
-rw-r--r--. 1 root root 4096 Mar  9 11:33 /sys/fs/lustre/ldlm/namespaces/MGC192.168.20.1@tcp/lru_size
-rw-r--r--. 1 root root 4096 Apr 16 02:09 /sys/fs/lustre/ldlm/namespaces/myth-MDT0000-mdc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:31 /sys/fs/lustre/ldlm/namespaces/myth-OST0000-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Apr 16 02:09 /sys/fs/lustre/ldlm/namespaces/myth-OST0001-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:32 /sys/fs/lustre/ldlm/namespaces/myth-OST0002-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:32 /sys/fs/lustre/ldlm/namespaces/myth-OST0003-osc-ffff979380fc1800/lru_size
-rw-r--r--. 1 root root 4096 Mar  9 11:31 /sys/fs/lustre/ldlm/namespaces/myth-OST0004-osc-ffff979380fc1800/lru_size
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;I believe the different timestamps in this case are because the MDT0000 and OST0001 devices were remounted after the filesystem was first mounted.  However, I haven&apos;t done any investigation on whether the mtime/ctime can be set differently for sysfs/procfs inodes, but I suspect they use regular &lt;tt&gt;struct inode&lt;/tt&gt; and could be modified appropriately.&lt;/p&gt;


&lt;p&gt;Another option would be to list the modified parameter names into an internal table and have a new parameter file that prints the modified parameter names.  This could potentially be tricky to implement, because it isn&apos;t always clear from the parameter handler itself what the full pathname to the modified parameter is.  However, this has the advantage that the parameter could easily be dumped (e.g. &quot;&lt;tt&gt;lctl get_param modified_params&lt;/tt&gt;&quot;) and would itself be included in a &quot;dump all parameters&quot; output like &quot;&lt;tt&gt;lctl get_param -R &apos;&amp;#42;&apos;&lt;/tt&gt;&quot;. &lt;/p&gt;

&lt;p&gt;In addition to dumping the &lt;b&gt;names&lt;/b&gt; of the modified parameters, it would be possible to actually keep a log of the original/new parameters, and what time they were changed, etc.  However, at that point we might just consider to log all parameter changes to &lt;tt&gt;/var/log/messages&lt;/tt&gt; so that they are readily available without any additional effort.  The main drawback of this is on large clusters with many clients, as this may produce a lot of log spam if 10000 clients all report &quot;&lt;tt&gt;parameter max_dirty_mb changed from 2048 to 4096&lt;/tt&gt;&quot; for dozens of parameters, especially if the contents are large.&lt;/p&gt;</description>
                <environment></environment>
        <key id="76767">LU-16931</key>
            <summary>add lctl mechanism (list_param?) to report changes to tunable parameters</summary>
                <type id="4" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</priority>
                        <status id="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="wc-triage">WC Triage</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                            <label>medium</label>
                    </labels>
                <created>Wed, 28 Jun 2023 19:38:48 +0000</created>
                <updated>Sat, 20 Jan 2024 05:41:14 +0000</updated>
                                                                                <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                            <comments>
                            <comment id="398890" author="adilger" created="Mon, 8 Jan 2024 22:06:48 +0000"  >&lt;p&gt;I was testing on an el8 client and it looks like the timestamps for parameters under &lt;tt&gt;/proc/fs/lustre&lt;/tt&gt; do &lt;b&gt;not&lt;/b&gt; change when written to:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# ls -l /proc/fs/lustre/lov/*
total 0
0 dr-xr-xr-x. 2 root root 0 Dec 21 00:23 pools/
0 -rw-r--r--. 1 root root 0 Dec 19 14:16 stripesize
0 -r--r--r--. 1 root root 0 Dec 21 00:23 target_obd
# lctl set_param lov.*.stripesize=8M
lov.myth-clilov-ffff9799f5c86000.stripesize=8M
# ls -l /proc/fs/lustre/lov/*
total 0
0 dr-xr-xr-x. 2 root root 0 Dec 21 00:23 pools/
0 -rw-r--r--. 1 root root 0 Dec 19 14:16 stripesize
0 -r--r--r--. 1 root root 0 Dec 21 00:23 target_obd
# stat /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
:
Access: 2023-12-19 14:16:05.558204389 -0700
Modify: 2023-12-19 14:16:05.558204389 -0700
Change: 2023-12-19 14:16:05.558204389 -0700
 Birth: -
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;I suspect all the timestamps are set when the &lt;tt&gt;procfs&lt;/tt&gt; file is first created.  However, that doesn&apos;t mean the mtime &lt;b&gt;can&apos;t&lt;/b&gt; be changed, just that it doesn&apos;t happen automatically today.&lt;/p&gt;

&lt;p&gt;As an aside, it isn&apos;t clear why &quot;&lt;tt&gt;stripesize&lt;/tt&gt;&quot; is still under &lt;tt&gt;/proc/fs/lustre&lt;/tt&gt; and not &lt;tt&gt;/sys/fs/lustre&lt;/tt&gt; with the other &lt;tt&gt;stripe&amp;#42;&lt;/tt&gt; parameters?&lt;/p&gt;

&lt;p&gt;The same is true for &lt;tt&gt;sysfs&lt;/tt&gt; files:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# ls -l /sys/fs/lustre/lov/stripe*
total 0
0 -rw-r--r--. 1 root root 4096 Dec 21 00:23 stripecount
0 -rw-r--r--. 1 root root 4096 Dec 21 00:23 stripeoffset
0 -rw-r--r--. 1 root root 4096 Dec 21 00:23 stripetype
# lctl set_param lov.*.stripecount=2
lov.myth-clilov-ffff9799f5c86000.stripecount=2
# ls -l /sys/fs/lustre/lov/stripe*
total 0
0 -rw-r--r--. 1 root root 4096 Dec 21 00:23 stripecount
0 -rw-r--r--. 1 root root 4096 Dec 21 00:23 stripeoffset
0 -rw-r--r--. 1 root root 4096 Dec 21 00:23 stripetype
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;and also &lt;tt&gt;debugfs&lt;/tt&gt; files:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# ls -l /sys/kernel/debug/lustre/mdc/myth-MDT0000-mdc-ffff9799f5c86000/stats
0 -rw-r--r--. 1 root root 0 Dec 19 14:16 stats
# lctl set_param mdc.*.stats=0
mdc.myth-MDT0000-mdc-ffff9799f5c86000.stats=0
# ls -l /sys/kernel/debug/lustre/mdc/myth-MDT0000-mdc-ffff9799f5c86000/stats
0 -rw-r--r--. 1 root root 0 Dec 19 14:16 stats
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, it &lt;b&gt;does&lt;/b&gt; seem possible to change the timestamps of these files:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# touch /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
# ls -l /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
0 -rw-r--r--. 1 root root 0 Jan  8 15:12 /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize
# touch /sys/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripecount
# ls -l /sys/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripecount
0 -rw-r--r--. 1 root root 4096 Jan  8 15:13 /sys/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripecount
# touch /sys/kernel/debug/lustre/mdc/myth-MDT0000-mdc-ffff9799f5c86000/stats
# ls -l /sys/kernel/debug/lustre/mdc/myth-MDT0000-mdc-ffff9799f5c86000/stats
0 -rw-r--r--. 1 root root 0 Jan  8 15:13 stats
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;And it appears that there are (as expected) separate timestamps stored for the atime, mtime, and ctime:&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;# touch -m /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
# stat /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
Access: 2024-01-08 15:15:57.938710185 -0700
Modify: 2024-01-08 15:16:28.310231110 -0700
Change: 2024-01-08 15:16:28.310231110 -0700
# touch -a /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
# stat /proc/fs/lustre/lov/myth-clilov-ffff9799f5c86000/stripesize 
Access: 2024-01-08 15:15:57.938710185 -0700
Modify: 2024-01-08 15:15:21.587283587 -0700
Change: 2024-01-08 15:15:57.938710185 -0700
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;so it looks like the kernel code that handles setting the parameters should update the mtime+ctime on writes and only the atime on reads.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="36381">LU-8066</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="52532">LU-11077</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="78645">LU-17237</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|i03p6v:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>