<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:50:29 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-12197] incorrect peer nids with discovery enabled</title>
                <link>https://jira.whamcloud.com/browse/LU-12197</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;The client side symptom is alternating success/failure of lnet ping to an oss. On the oss we see:&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;# lnetctl peer show --nid n1-ib0@o2ib
peer:
&#160; &#160; - primary nid: xxx.xxx.xxx.17@o2ib
&#160; &#160; &#160; Multi-Rail: True
&#160; &#160; &#160; peer ni:
&#160; &#160; &#160; &#160; - nid: xxx.xxx.xxx.17@o2ib
&#160; &#160; &#160; &#160; &#160; state: NA
&#160; &#160; &#160; &#160; - nid: xxx.xxx.xxx.182@o2ib
&#160; &#160; &#160; &#160; &#160; state: NA
# lnetctl peer show --nid n2-ib0@o2ib
peer:
&#160; &#160; - primary nid: xxx.xxx.xxx.17@o2ib
&#160; &#160; &#160; Multi-Rail: True
&#160; &#160; &#160; peer ni:
&#160; &#160; &#160; &#160; - nid: xxx.xxx.xxx.17@o2ib
&#160; &#160; &#160; &#160; &#160; state: NA
&#160; &#160; &#160; &#160; - nid: xxx.xxx.xxx.182@o2ib
&#160; &#160; &#160; &#160; &#160; state: NA&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;where n1 has ipaddr ending in 182, and n2 has ipaddr ending 17. &lt;/p&gt;

&lt;p&gt;The results in logs is lots of timeouts, put NAKs, mount failures and general chaos including plenty of the following message:&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;kernel: LustreError: 21309:0:(events.c:450:server_bulk_callback()) event type 3, status -61, desc ffff9c46e0303200 &lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The logs lead us to believe there were IB problems, but the fabric was found to be clean and responsive between the affected client nodes and oss servers.&lt;/p&gt;

&lt;p&gt;Planning to turn off discovery going forward. I&apos;ll leave a few clients drained for awhile in case there is info you might need. &lt;/p&gt;

&lt;p&gt;fyi, rebooting the client does not change the behavior, rebooting the server clears it. Also manually deleting the incorrect peer nid on the server and re-adding the correct info for the missing peer also clears it.&lt;/p&gt;

&lt;p&gt;Also, clients are running socket direct, but only one IPoIB interface is configured and in use by lnet.&lt;/p&gt;</description>
                <environment>ARM clients: kernel 4.14.0-115.2.2.el7a.aarch64 MLNX_OFED_LINUX-4.5-1.0.1.0 (OFED-4.5-1.0.1)&lt;br/&gt;
x86 servers: rhel 7.6, same mofed&lt;br/&gt;
2.12.0 no patches</environment>
        <key id="55438">LU-12197</key>
            <summary>incorrect peer nids with discovery enabled</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="3">Duplicate</resolution>
                                        <assignee username="ashehata">Amir Shehata</assignee>
                                    <reporter username="ruth.klundt@gmail.com">Ruth Klundt</reporter>
                        <labels>
                            <label>arm</label>
                    </labels>
                <created>Thu, 18 Apr 2019 19:55:57 +0000</created>
                <updated>Sat, 12 Oct 2019 15:09:28 +0000</updated>
                            <resolved>Sat, 12 Oct 2019 15:09:23 +0000</resolved>
                                    <version>Lustre 2.12.0</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>7</watches>
                                                                            <comments>
                            <comment id="246080" author="pjones" created="Fri, 19 Apr 2019 13:09:53 +0000"  >&lt;p&gt;Thanks Ruth&lt;/p&gt;</comment>
                            <comment id="246584" author="pjones" created="Wed, 1 May 2019 16:30:33 +0000"  >&lt;p&gt;Sonia&lt;/p&gt;

&lt;p&gt;Could you please assist with this issue?&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="249616" author="mtimmerman" created="Thu, 20 Jun 2019 17:45:07 +0000"  >&lt;p&gt;&lt;font color=&quot;#000000&quot;&gt;Sonia,&lt;/font&gt;&lt;/p&gt;

&lt;p&gt;&lt;font color=&quot;#000000&quot;&gt;&#160;&lt;/font&gt;&lt;/p&gt;

&lt;p&gt;&lt;font color=&quot;#000000&quot;&gt;This bug reported as HP-235 and &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12197&quot; title=&quot;incorrect peer nids with discovery enabled&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12197&quot;&gt;&lt;del&gt;LU-12197&lt;/del&gt;&lt;/a&gt; that were originally entered as minor for our customer. This has now become a major issue. Can you change the priority to major and has anything been done with the problem so far?&lt;/font&gt;&lt;/p&gt;

&lt;p&gt;&lt;font color=&quot;#000000&quot;&gt;&#160;&lt;/font&gt;&lt;/p&gt;

&lt;p&gt;&lt;font color=&quot;#000000&quot;&gt;Thanks. &lt;/font&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;&lt;font color=&quot;#000000&quot;&gt;Mike &lt;/font&gt;&lt;/p&gt;</comment>
                            <comment id="250017" author="sharmaso" created="Tue, 25 Jun 2019 18:57:47 +0000"  >&lt;p&gt;Hi Mike,&lt;/p&gt;

&lt;p&gt;I tried to reproduce this on my local VM setup (with tcp) and could not reproduce the issue. When I run &quot;lnetctl peer show&quot;, it showed nids of different peers under their own primary nid. &lt;/p&gt;

&lt;p&gt;Can you please list here how you have configured the nodes and also the exact steps you follow starting from configuration of the nodes that leads to the issue when you see nids of different peers showing up under the primary nid of 1 peer.&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;</comment>
                            <comment id="250018" author="mtimmerman" created="Tue, 25 Jun 2019 19:28:24 +0000"  >&lt;p&gt;I have asked Ruth Klundt &amp;lt;rklundt@sandia.gov&amp;gt;&#160;and Steve Champion &amp;lt;stephen.champion@hpe.com&amp;gt; to weigh in on this as they were the ones who configured and discovered the problem.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;Thanks.&lt;/p&gt;</comment>
                            <comment id="250021" author="ruth.klundt@gmail.com" created="Tue, 25 Jun 2019 20:01:27 +0000"  >&lt;p&gt;software stack described above.&lt;/p&gt;

&lt;p&gt;2 MDS nodes, 1 MDT each. 40 OSS nodes, 2 zfs OSTs each. module params:&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;servers:
options lnet networks=o2ib0(ib0)
options ko2iblnd map_on_demand=16
options ko2iblnd timeout=100
options ko2iblnd credits=512
clients:
options lnet live_router_check_interval=60
options lnet dead_router_check_interval=60
options lnet check_routers_before_use=1
options ko2iblnd timeout=100
options ko2iblnd credits=512&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Steps before seeing this issue - basically reboot 2500+ nodes and some of them multiple times.&lt;/p&gt;

&lt;p&gt;Out of the 2500+ clients I found the error on 4 pairs of nodes, one pair on each of 4 distinct servers out of the 40 OSS nodes.&lt;/p&gt;

&lt;p&gt;Some relevant items are that:&lt;/p&gt;

&lt;p&gt;The servers and clients are running mellanox stack as listed above. As I said above, the servers have only one&#160;port into the IB network. The clients also have only one port, which appears as 2 due to the use of the mellanox socket direct feature. Only one of the ports is configured for use by lnet, and in fact only one (ib0) has an IPoIB address configured. So&#160;if the code is detecting another port&#160;automatically via some IB call&#160;and&#160;assuming it can be used&#160;that is an error. I can imagine that bad assumption leading to addition of an inappropriate nid from some list to the wrong client under high load conditions, exposing some concurrency flaw not previously seen.&#160;&lt;/p&gt;

&lt;p&gt;It seems unlikely to be reproducible on a vm with tcp, and I&apos;m afraid that a reproducer would have to come from HPE internal testing if possible at all. The machine where this occurred is in production with Dynamic Discovery disabled. It&apos;s likely that someone familiar with Dynamic Discovery is going to have to look at the code and decipher how that feature is doing the automatic detection.&lt;/p&gt;

&lt;p&gt;I think my point here is that nothing on this machine should have been detected as multirail.&#160;&lt;/p&gt;

&lt;p&gt;If you have other more specific questions about the node configuration I&apos;ll be glad to answer what I can.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="250791" author="schamp" created="Sat, 6 Jul 2019 05:54:53 +0000"  >&lt;p&gt;I talked to Amir about this at LUG.&lt;/p&gt;

&lt;p&gt;Amir pointed to queued patches, and suggested that the patches submitted for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11478&quot; title=&quot;LNet: discovery sequence numbers could be misleading&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11478&quot;&gt;&lt;del&gt;LU-11478&lt;/del&gt;&lt;/a&gt; may address this. From my reading, I think that fixing &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11478&quot; title=&quot;LNet: discovery sequence numbers could be misleading&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11478&quot;&gt;&lt;del&gt;LU-11478&lt;/del&gt;&lt;/a&gt; will allow the problem to be corrected automatically, but I am not sure that it will actually prevent the problem from occurring.&lt;/p&gt;

&lt;p&gt;&quot;The problem&quot; being insertion of the wrong nid to a peer&apos;s list of NIs.  I think there is a fair chance to find this through code inspection by someone more familiar with the peer discovery process.  My suspicion is that a peer node id is held by an unlocked reference as an peer ni is inserted.  I noticed &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12264&quot; title=&quot;The lnet peer discovery queue (lnet_peer.lp_dc_pendq) is susceptible to concurrent manipulation&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12264&quot;&gt;&lt;del&gt;LU-12264&lt;/del&gt;&lt;/a&gt; in the queued patches - it looks very close, but I&apos;m not sure that this specific problem is addressed.&lt;/p&gt;

&lt;p&gt;I suspect that the number of peer entries on the host is a factor, so duplication may not be possible without a large cluster.&lt;/p&gt;</comment>
                            <comment id="251342" author="pjones" created="Sat, 13 Jul 2019 15:44:21 +0000"  >&lt;p&gt;Amir&lt;/p&gt;

&lt;p&gt;Should we look to include the fix for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11478&quot; title=&quot;LNet: discovery sequence numbers could be misleading&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11478&quot;&gt;&lt;del&gt;LU-11478&lt;/del&gt;&lt;/a&gt; onto b2_12 as a first step?&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="253601" author="ashehata" created="Mon, 26 Aug 2019 16:18:36 +0000"  >&lt;p&gt;Yes. I added it to the list of patches we ought to port to b2_12 here &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12666&quot; title=&quot;patches to backport to b2_12&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12666&quot;&gt;&lt;del&gt;LU-12666&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="256301" author="pjones" created="Sat, 12 Oct 2019 15:09:23 +0000"  >&lt;p&gt;The fix is included in 2.12.3 which is in release testing ATM&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                            <outwardlinks description="duplicates">
                                        <issuelink>
            <issuekey id="53520">LU-11478</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                                        </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|i00f1j:</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>