<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:15:53 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-8246] Leaks on ldlm granted locks counter on MDS leading to canceling loop</title>
                <link>https://jira.whamcloud.com/browse/LU-8246</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;A performance problem at one of our customers led us to find that the granted ldlm locks counter (found in  /proc/fs/lustre/ldlm/namespaces/mdt-fsname-MDT0000_UUID/pool/granted) is actually missing some decrements in some conditions (yet to be determined).&lt;/p&gt;

&lt;p&gt;This leads after some time to have this counter largely exceed the number found in /proc/fs/lustre/ldlm/namespaces/mdt-fsname-MDT0000_UUID/pool/limit. &lt;/p&gt;

&lt;p&gt;See here:&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;[root@prolixmds1 pool]# pwd
/proc/fs/lustre/ldlm/namespaces/mdt-scratch-MDT0000_UUID/pool
[root@prolixmds1 pool]# cat limit
3203616
[root@prolixmds1 pool]# cat granted
54882822
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;However, summing up all granted locks as seen by the all the clients, we get only 16k locks, which is also consistent with the slab consumption on the MDS.&lt;/p&gt;

&lt;p&gt;Once above the limit, the MDS will then constantly try to cancel locks, even those which are not above max_age. Clients then reacquire the locks, but lose time in the process (then showing the performance problem).&lt;/p&gt;

&lt;p&gt;Note that as this is only the counter which is false, we don&apos;t have any resource overconsumption tied to this problem.&lt;/p&gt;

&lt;p&gt;We found that this problem is also seen on 2.8.&lt;br/&gt;
Can you help find where the leak comes from ?&lt;/p&gt;

&lt;p&gt;I also wonder if there is any relation with the last comment from Shuichi Ihara in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-5727&quot; title=&quot;MDS OOMs with 2.5.3 clients and lru_size != 0&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-5727&quot;&gt;&lt;del&gt;LU-5727&lt;/del&gt;&lt;/a&gt;.&lt;br/&gt;
I also think Christopher Morrone pointed this out &lt;a href=&quot;https://jira.hpdd.intel.com/browse/LU-6529?focusedCommentId=125773&amp;amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-125773&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;here&lt;/a&gt;&lt;/p&gt;</description>
                <environment></environment>
        <key id="37423">LU-8246</key>
            <summary>Leaks on ldlm granted locks counter on MDS leading to canceling loop</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</priority>
                        <status id="5" iconUrl="https://jira.whamcloud.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="green">Oleg Drokin</assignee>
                                    <reporter username="spiechurski">Sebastien Piechurski</reporter>
                        <labels>
                    </labels>
                <created>Tue, 7 Jun 2016 09:49:55 +0000</created>
                <updated>Thu, 14 Jun 2018 21:41:18 +0000</updated>
                            <resolved>Sun, 30 Oct 2016 11:40:40 +0000</resolved>
                                    <version>Lustre 2.5.3</version>
                    <version>Lustre 2.8.0</version>
                                    <fixVersion>Lustre 2.9.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>7</watches>
                                                                            <comments>
                            <comment id="154930" author="pjones" created="Tue, 7 Jun 2016 17:07:56 +0000"  >&lt;p&gt;Oleg&lt;/p&gt;

&lt;p&gt;Could you please advise?&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="155978" author="green" created="Thu, 16 Jun 2016 19:26:12 +0000"  >&lt;p&gt;Hm, you are actually right.&lt;/p&gt;

&lt;p&gt;I checked some of my nodes and see the numbers are out of whack too, so I added a simple refcounter into every lock to see how many times did we call ldlm_pool_add/del and it seems to be a common occurence that we call ldlm_pool_add (from ldlm_lock_grant) twice, but free it only once.&lt;/p&gt;

&lt;p&gt;The second addition comes via:&lt;/p&gt;
&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;[  353.612043] Increaing pl_granted but lock ffff880046a3cc40 refc is already 1
[  353.612660] CPU: 7 PID: 3654 Comm: mdt01_002 Tainted: G           OE  ------------   3.10.0-debug #1
[  353.613777] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  353.614385]  ffff880046a3cc40 0000000095009a39 ffff880080ef7840 ffffffff816fe7c0
[  353.616879]  ffff880080ef7890 ffffffffa0556e5d ffff880046a3ceb8 ffff880080ef78a8
[  353.618213]  ffff880080ef7890 0000000095009a39 ffff880046a3cc40 ffff880042a36e80
[  353.619201] Call Trace:
[  353.619815]  [&amp;lt;ffffffff816fe7c0&amp;gt;] dump_stack+0x19/0x1b
[  353.620385]  [&amp;lt;ffffffffa0556e5d&amp;gt;] ldlm_pool_add+0x16d/0x1f0 [ptlrpc]
[  353.620931]  [&amp;lt;ffffffffa052162e&amp;gt;] ldlm_grant_lock+0x11e/0x780 [ptlrpc]
[  353.621564]  [&amp;lt;ffffffffa0554382&amp;gt;] ldlm_process_inodebits_lock+0x362/0x420 [ptlrpc]
[  353.622676]  [&amp;lt;ffffffffa052323e&amp;gt;] ldlm_lock_enqueue+0x3fe/0x940 [ptlrpc]
[  353.623327]  [&amp;lt;ffffffffa053f126&amp;gt;] ldlm_cli_enqueue_local+0x1c6/0x850 [ptlrpc]
[  353.623984]  [&amp;lt;ffffffffa053c480&amp;gt;] ? ldlm_expired_completion_wait+0x250/0x250 [ptlrpc]
[  353.625077]  [&amp;lt;ffffffffa0b9a570&amp;gt;] ? mdt_register_seq_exp+0x2e0/0x2e0 [mdt]
[  353.625710]  [&amp;lt;ffffffffa0ba947a&amp;gt;] mdt_object_local_lock+0x52a/0xb00 [mdt]
[  353.626344]  [&amp;lt;ffffffffa0b9a570&amp;gt;] ? mdt_register_seq_exp+0x2e0/0x2e0 [mdt]
[  353.627001]  [&amp;lt;ffffffffa053c480&amp;gt;] ? ldlm_expired_completion_wait+0x250/0x250 [ptlrpc]
[  353.628095]  [&amp;lt;ffffffffa0ba9aae&amp;gt;] mdt_object_lock_internal+0x5e/0x2f0 [mdt]
[  353.628728]  [&amp;lt;ffffffffa0ba9ec0&amp;gt;] mdt_reint_object_lock+0x20/0x60 [mdt]
[  353.629362]  [&amp;lt;ffffffffa0bc167b&amp;gt;] mdt_reint_setattr+0x67b/0x1130 [mdt]
[  353.630001]  [&amp;lt;ffffffffa0bc21b0&amp;gt;] mdt_reint_rec+0x80/0x210 [mdt]
[  353.630612]  [&amp;lt;ffffffffa0ba4f8c&amp;gt;] mdt_reint_internal+0x5dc/0x940 [mdt]
[  353.631246]  [&amp;lt;ffffffffa0baee87&amp;gt;] mdt_reint+0x67/0x140 [mdt]
[  353.631888]  [&amp;lt;ffffffffa05ce835&amp;gt;] tgt_request_handle+0x925/0x1330 [ptlrpc]
[  353.632567]  [&amp;lt;ffffffffa057c261&amp;gt;] ptlrpc_server_handle_request+0x231/0xab0 [ptlrpc]
[  353.633678]  [&amp;lt;ffffffffa057aae8&amp;gt;] ? ptlrpc_wait_event+0xb8/0x370 [ptlrpc]
[  353.634353]  [&amp;lt;ffffffffa0580068&amp;gt;] ptlrpc_main+0xa58/0x1dc0 [ptlrpc]
[  353.635023]  [&amp;lt;ffffffff81707f27&amp;gt;] ? _raw_spin_unlock_irq+0x27/0x50
[  353.635657]  [&amp;lt;ffffffffa057f610&amp;gt;] ? ptlrpc_register_service+0xe70/0xe70 [ptlrpc]
[  353.636433]  [&amp;lt;ffffffff810a404a&amp;gt;] kthread+0xea/0xf0
[  353.636860]  [&amp;lt;ffffffff810a3f60&amp;gt;] ? kthread_create_on_node+0x140/0x140
[  353.637301]  [&amp;lt;ffffffff81711758&amp;gt;] ret_from_fork+0x58/0x90
[  353.637724]  [&amp;lt;ffffffff810a3f60&amp;gt;] ? kthread_create_on_node+0x140/0x140
[  353.638163] Original trace:
[  353.638573]     [&amp;lt;ffffffffa0556da0&amp;gt;] ldlm_pool_add+0xb0/0x1f0 [ptlrpc]
[  353.639218]     [&amp;lt;ffffffffa052162e&amp;gt;] ldlm_grant_lock+0x11e/0x780 [ptlrpc]
[  353.639950]     [&amp;lt;ffffffffa0554323&amp;gt;] ldlm_process_inodebits_lock+0x303/0x420 [ptlrpc]
[  353.641051]     [&amp;lt;ffffffffa05238a3&amp;gt;] ldlm_reprocess_queue+0x123/0x230 [ptlrpc]
[  353.642311]     [&amp;lt;ffffffffa0523e50&amp;gt;] ldlm_reprocess_all+0x120/0x310 [ptlrpc]
[  353.643068]     [&amp;lt;ffffffffa05466a5&amp;gt;] ldlm_request_cancel+0x475/0x710 [ptlrpc]
[  353.643810]     [&amp;lt;ffffffffa054c78a&amp;gt;] ldlm_handle_cancel+0xba/0x250 [ptlrpc]
[  353.644555]     [&amp;lt;ffffffffa054ca61&amp;gt;] ldlm_cancel_handler+0x141/0x490 [ptlrpc]
[  353.645330]     [&amp;lt;ffffffffa057c261&amp;gt;] ptlrpc_server_handle_request+0x231/0xab0 [ptlrpc]
[  353.651045]     [&amp;lt;ffffffffa0580068&amp;gt;] ptlrpc_main+0xa58/0x1dc0 [ptlrpc]
[  353.651478]     [&amp;lt;ffffffff810a404a&amp;gt;] kthread+0xea/0xf0
[  353.651899]     [&amp;lt;ffffffff81711758&amp;gt;] ret_from_fork+0x58/0x90
[  353.652327]     [&amp;lt;ffffffffffffffff&amp;gt;] 0xffffffffffffffff

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="155980" author="green" created="Thu, 16 Jun 2016 19:31:18 +0000"  >&lt;p&gt;so... a race between a lock request and lock cancel that leads to two granting threads, I guess?&lt;/p&gt;</comment>
                            <comment id="155986" author="green" created="Thu, 16 Jun 2016 20:12:22 +0000"  >&lt;p&gt;Ok, o the race plays like this:&lt;/p&gt;

&lt;p&gt;We do first enqueue (in ldlm_process_inodebits_lock()), meet a conflicting lock, add ourselves into waiting list and call ldlm_run_ast_work()&lt;br/&gt;
At the same time cancel arrives for the lock we are conflicting on, sees our lock could be granted and grants it (the original trace)&lt;br/&gt;
Now we get back here, and receive ERESTART as return of ldlm_run_ast_work(), jump to again label, see there are no conflicts and grant us again.&lt;/p&gt;

&lt;p&gt;Every grant call increases the pl_granted counter, but since the lock is the same there is only one decrease.&lt;/p&gt;

&lt;p&gt;Hm, in fact there&apos;s even a check for that just for extent only lock, fixed as part of bug 11300.&lt;/p&gt;

&lt;p&gt;I&apos;ll try to do a similar patch for plain and ibits locks. The flock is more convoluted and would not play into this particular problem.&lt;/p&gt;</comment>
                            <comment id="155989" author="gerrit" created="Thu, 16 Jun 2016 20:25:42 +0000"  >&lt;p&gt;Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: &lt;a href=&quot;http://review.whamcloud.com/20839&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/20839&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-8246&quot; title=&quot;Leaks on ldlm granted locks counter on MDS leading to canceling loop&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-8246&quot;&gt;&lt;del&gt;LU-8246&lt;/del&gt;&lt;/a&gt; ldlm: Do not grant a lock twice in a race&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 7c8e41dfabb4e2bead4080a993903b683152bb5c&lt;/p&gt;</comment>
                            <comment id="156020" author="green" created="Thu, 16 Jun 2016 23:31:00 +0000"  >&lt;p&gt;btw to guge number of locks MDT has actually granted in total, instead of counting all clients, just check /proc/fs/lustre/ldlm/namespaces/mdt-lustre-MDT0000_UUID/lock_count&lt;br/&gt;
This number includes number of locks given to clients + locks not given anywhere but held by the server internally (the number fluctuates of course, but if it&apos;s too different from the granted number you know there&apos;s a problem. In fact I wonder why do we need to have two trackers for essentially the same value - perhaps we can just drop the one from pools? Though I guess in pools we track number of locks granted and the namespace it&apos;s number of locks total - granted and ungranted)&lt;/p&gt;</comment>
                            <comment id="156311" author="spiechurski" created="Tue, 21 Jun 2016 08:18:39 +0000"  >&lt;p&gt;Great ! Thanks Oleg for the analysis.&lt;/p&gt;</comment>
                            <comment id="171718" author="gerrit" created="Sun, 30 Oct 2016 02:50:35 +0000"  >&lt;p&gt;Oleg Drokin (oleg.drokin@intel.com) merged in patch &lt;a href=&quot;http://review.whamcloud.com/20839/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/20839/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-8246&quot; title=&quot;Leaks on ldlm granted locks counter on MDS leading to canceling loop&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-8246&quot;&gt;&lt;del&gt;LU-8246&lt;/del&gt;&lt;/a&gt; ldlm: Do not grant a lock twice in a race&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 7d4106cd9fd9ef48822d19c35a711570be25d5ee&lt;/p&gt;</comment>
                            <comment id="171719" author="pjones" created="Sun, 30 Oct 2016 11:40:40 +0000"  >&lt;p&gt;Landed for 2.9&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                                        </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="40001">LU-8634</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|hzydtz:</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>