<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 03:11:00 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-14582] nested LDLM locks cause evictions due to RPC-in-flight limit</title>
                <link>https://jira.whamcloud.com/browse/LU-14582</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;clients get evicted from MDS during racer runs quite often. this is due to nested LDLM locks in DNE setup. say, thread T is working on a client side:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;lmv_intent_lock() tries to get LOOKUP|UPDATE for a given object&lt;/li&gt;
	&lt;li&gt;MDS1 returns just LOOKUP + FID (lock L1)&lt;/li&gt;
	&lt;li&gt;lmv_intent_remote() asks MDS2 for UPDATE and attributes still holding the lock from MDS1 (potentially lock L2)&lt;br/&gt;
if the first object is contended, then the following situation is possible:&lt;/li&gt;
	&lt;li&gt;all slots (obd_get_request_slots()) are busy with LDLM_ENQUEUE against the first object&lt;/li&gt;
	&lt;li&gt;the corresponding LDLM resource on MDS1 can&apos;t grant those locks due to some one else incompatible with granted lock L1&lt;/li&gt;
	&lt;li&gt;T can&apos;t proceed with L2 due to slots busy, thus can&apos;t release L1&lt;/li&gt;
&lt;/ul&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;
Lustre: mdt00_027: service thread pid 13168 was inactive &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; 40.338 seconds. The thread might be hung, or it might only be slow and will resume later. Dumping the stack trace &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; debugging purposes:
Pid: 13168, comm: mdt00_027 4.18.0 #36 SMP Thu Mar 25 14:56:29 MSK 2021
Call Trace:
[&amp;lt;0&amp;gt;] ldlm_completion_ast+0x77c/0x8d0 [ptlrpc]
[&amp;lt;0&amp;gt;] ldlm_cli_enqueue_fini+0x9fc/0xe90 [ptlrpc]
[&amp;lt;0&amp;gt;] ldlm_cli_enqueue+0x4d9/0x990 [ptlrpc]
[&amp;lt;0&amp;gt;] osp_md_object_lock+0x154/0x290 [osp]
[&amp;lt;0&amp;gt;] lod_object_lock+0x11a/0x780 [lod]
[&amp;lt;0&amp;gt;] mdt_remote_object_lock_try+0x140/0x370 [mdt]
[&amp;lt;0&amp;gt;] mdt_remote_object_lock+0x1a/0x20 [mdt]
[&amp;lt;0&amp;gt;] mdt_reint_unlink+0x70d/0x2060 [mdt]
[&amp;lt;0&amp;gt;] mdt_reint_rec+0x117/0x240 [mdt]
[&amp;lt;0&amp;gt;] mdt_reint_internal+0x90c/0xab0 [mdt]
[&amp;lt;0&amp;gt;] mdt_reint+0x57/0x100 [mdt]
[&amp;lt;0&amp;gt;] tgt_request_handle+0xbe0/0x1970 [ptlrpc]
[&amp;lt;0&amp;gt;] ptlrpc_main+0x134f/0x30e0 [ptlrpc]
[&amp;lt;0&amp;gt;] kthread+0x100/0x140
[&amp;lt;0&amp;gt;] ret_from_fork+0x24/0x30
[&amp;lt;0&amp;gt;] 0xffffffffffffffff
Lustre: mdt00_001: service thread pid 7729 was inactive &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; 65.046 seconds. The thread might be hung, or it might only be slow and will resume later. Dumping the stack trace &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; debugging purposes:
Pid: 10908, comm: mdt00_037 4.18.0 #36 SMP Thu Mar 25 14:56:29 MSK 2021
Lustre: Skipped 1 previous similar message
Call Trace:
[&amp;lt;0&amp;gt;] ldlm_completion_ast+0x77c/0x8d0 [ptlrpc]
[&amp;lt;0&amp;gt;] ldlm_cli_enqueue_local+0x27d/0x7f0 [ptlrpc]
[&amp;lt;0&amp;gt;] mdt_object_local_lock+0x479/0xad0 [mdt]
[&amp;lt;0&amp;gt;] mdt_object_lock_internal+0x1d3/0x3f0 [mdt]
[&amp;lt;0&amp;gt;] mdt_getattr_name_lock+0xdb5/0x1f80 [mdt]
[&amp;lt;0&amp;gt;] mdt_intent_getattr+0x25b/0x420 [mdt]
[&amp;lt;0&amp;gt;] mdt_intent_policy+0x659/0xee0 [mdt]
[&amp;lt;0&amp;gt;] ldlm_lock_enqueue+0x418/0x9b0 [ptlrpc]
[&amp;lt;0&amp;gt;] ldlm_handle_enqueue0+0x5d8/0x16c0 [ptlrpc]
[&amp;lt;0&amp;gt;] tgt_enqueue+0x9f/0x200 [ptlrpc]
[&amp;lt;0&amp;gt;] tgt_request_handle+0xbe0/0x1970 [ptlrpc]
[&amp;lt;0&amp;gt;] ptlrpc_main+0x134f/0x30e0 [ptlrpc]
[&amp;lt;0&amp;gt;] kthread+0x100/0x140
[&amp;lt;0&amp;gt;] ret_from_fork+0x24/0x30
[&amp;lt;0&amp;gt;] 0xffffffffffffffff
Pid: 7729, comm: mdt00_001 4.18.0 #36 SMP Thu Mar 25 14:56:29 MSK 2021
Call Trace:
[&amp;lt;0&amp;gt;] ldlm_completion_ast+0x77c/0x8d0 [ptlrpc]
[&amp;lt;0&amp;gt;] ldlm_cli_enqueue_local+0x27d/0x7f0 [ptlrpc]
[&amp;lt;0&amp;gt;] mdt_object_local_lock+0x539/0xad0 [mdt]
[&amp;lt;0&amp;gt;] mdt_object_lock_internal+0x1d3/0x3f0 [mdt]
[&amp;lt;0&amp;gt;] mdt_getattr_name_lock+0x78c/0x1f80 [mdt]
[&amp;lt;0&amp;gt;] mdt_intent_getattr+0x25b/0x420 [mdt]
[&amp;lt;0&amp;gt;] mdt_intent_policy+0x659/0xee0 [mdt]
[&amp;lt;0&amp;gt;] ldlm_lock_enqueue+0x418/0x9b0 [ptlrpc]
[&amp;lt;0&amp;gt;] ldlm_handle_enqueue0+0x5d8/0x16c0 [ptlrpc]
[&amp;lt;0&amp;gt;] tgt_enqueue+0x9f/0x200 [ptlrpc]
[&amp;lt;0&amp;gt;] tgt_request_handle+0xbe0/0x1970 [ptlrpc]
[&amp;lt;0&amp;gt;] ptlrpc_main+0x134f/0x30e0 [ptlrpc]
[&amp;lt;0&amp;gt;] kthread+0x100/0x140
[&amp;lt;0&amp;gt;] ret_from_fork+0x24/0x30
[&amp;lt;0&amp;gt;] 0xffffffffffffffff
Lustre: mdt00_018: service thread pid 10527 was inactive &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; 65.062 seconds. Watchdog stack traces are limited to 3 per 300 seconds, skipping &lt;span class=&quot;code-keyword&quot;&gt;this&lt;/span&gt; one.
LustreError: 7718:0:(ldlm_lockd.c:260:expired_lock_main()) ### lock callback timer expired after 101s: evicting client at 0@lo  ns: mdt-lustre-MDT0001_UUID lock: 00000000bd306e1a/0xfbfedfd6efc4a594 lrc: 3/0,0 mode: PR/PR res: [0x240000403:0x172f:0x0].0x0 bits 0x13/0x0 rrc: 3 type: IBT gid 0 flags: 0x60200400000020 nid: 0@lo remote: 0xfbfedfd6efc498ba expref: 705 pid: 11012 timeout: 739 lvb_type: 0
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
        <key id="63645">LU-14582</key>
            <summary>nested LDLM locks cause evictions due to RPC-in-flight limit</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</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="bzzz">Alex Zhuravlev</reporter>
                        <labels>
                    </labels>
                <created>Mon, 5 Apr 2021 06:50:12 +0000</created>
                <updated>Fri, 26 Nov 2021 22:45:13 +0000</updated>
                                                            <fixVersion>Lustre 2.16.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>6</watches>
                                                                            <comments>
                            <comment id="297784" author="bzzz" created="Mon, 5 Apr 2021 06:51:54 +0000"  >&lt;p&gt;I tend to think we don&apos;t really need to hold the first lock during enqueue for UPDATE to another MDS.&lt;/p&gt;</comment>
                            <comment id="297814" author="adilger" created="Mon, 5 Apr 2021 17:03:28 +0000"  >&lt;p&gt;I was going to say the same - once the lookup is complete and we have the remote FID, there is no benefit to holding the first lock. &lt;/p&gt;</comment>
                            <comment id="297815" author="adilger" created="Mon, 5 Apr 2021 17:05:03 +0000"  >&lt;p&gt;How hard would it be to make a patch to fix this?  We definitely see several different DLM timeouts in production these days, and fixing them would be great. &lt;/p&gt;</comment>
                            <comment id="297818" author="bzzz" created="Mon, 5 Apr 2021 17:25:55 +0000"  >&lt;p&gt;have to try.. just to release the lock sooner seem to be trivial (in lmv_intent_remote()), but AFAIU this is not enouch as normally we set lock&apos;s data with mdc_set_lock_data() in llite&lt;/p&gt;</comment>
                            <comment id="298035" author="bzzz" created="Wed, 7 Apr 2021 04:42:33 +0000"  >&lt;p&gt;there are another cases with nested locks:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;lmv_intent_lookup() -&amp;gt; lmv_revalidate_slaves()&lt;/li&gt;
	&lt;li&gt;ll_prep_inode() -&amp;gt; lmv_revalidate_slaves()&lt;/li&gt;
&lt;/ul&gt;
</comment>
                            <comment id="298329" author="adilger" created="Fri, 9 Apr 2021 04:19:07 +0000"  >&lt;p&gt;Oleg, Lai, any comment on this?&lt;/p&gt;</comment>
                            <comment id="298513" author="laisiyao" created="Mon, 12 Apr 2021 06:44:26 +0000"  >&lt;p&gt;Yes, client should avoid holding locks, but it&apos;s bit nasty for client layer: inode and dentry preparations need to be registered as callback, and called in LMV after successful LOOKUP lock.&lt;/p&gt;</comment>
                    </comments>
                    <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|i01rav:</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>