<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:34:13 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-3474] MDS LBUG on unlink?</title>
                <link>https://jira.whamcloud.com/browse/LU-3474</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Hi,&lt;/p&gt;

&lt;p&gt;We have been testing v2.4 and have hit this LBUG which we have never experienced in v1.8.x for similar workloads. It looks like it is related to do an rm/unlink on certain files. I had to abort recovery and stop the ongoing file deletion in order to keep the MDS from repeatedly crashing with the same LBUG. We can supply more debug info should you need it.&lt;/p&gt;

&lt;p&gt;Cheers,&lt;/p&gt;

&lt;p&gt;Daire&lt;/p&gt;


&lt;p&gt;&amp;lt;0&amp;gt;LustreError: 6274:0:(linkea.c:169:linkea_links_find()) ASSERTION( ldata-&amp;gt;ld_leh != ((void *)0) ) failed: &lt;br/&gt;
&amp;lt;0&amp;gt;LustreError: 6274:0:(linkea.c:169:linkea_links_find()) LBUG&lt;br/&gt;
&amp;lt;4&amp;gt;Pid: 6274, comm: mdt01_004&lt;br/&gt;
&amp;lt;4&amp;gt;&lt;br/&gt;
&amp;lt;4&amp;gt;Call Trace:&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa044b895&amp;gt;&amp;#93;&lt;/span&gt; libcfs_debug_dumpstack+0x55/0x80 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa044be97&amp;gt;&amp;#93;&lt;/span&gt; lbug_with_loc+0x47/0xb0 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa05b47d6&amp;gt;&amp;#93;&lt;/span&gt; linkea_links_find+0x186/0x190 &lt;span class=&quot;error&quot;&gt;&amp;#91;obdclass&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b87206&amp;gt;&amp;#93;&lt;/span&gt; ? mdo_xattr_get+0x26/0x30 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b8a645&amp;gt;&amp;#93;&lt;/span&gt; mdd_linkea_prepare+0x95/0x430 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b8ab01&amp;gt;&amp;#93;&lt;/span&gt; mdd_links_rename+0x121/0x540 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b8eae6&amp;gt;&amp;#93;&lt;/span&gt; mdd_unlink+0xb86/0xe30 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e0db98&amp;gt;&amp;#93;&lt;/span&gt; mdo_unlink+0x18/0x50 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e10f40&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_unlink+0x820/0x1010 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e0d891&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_rec+0x41/0xe0 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0df2b03&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_internal+0x4c3/0x780 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0df2e04&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint+0x44/0xe0 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0df7ab8&amp;gt;&amp;#93;&lt;/span&gt; mdt_handle_common+0x648/0x1660 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e31165&amp;gt;&amp;#93;&lt;/span&gt; mds_regular_handle+0x15/0x20 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730388&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_server_handle_request+0x398/0xc60 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa044c5de&amp;gt;&amp;#93;&lt;/span&gt; ? cfs_timer_arm+0xe/0x10 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa045dd8f&amp;gt;&amp;#93;&lt;/span&gt; ? lc_watchdog_touch+0x6f/0x170 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa07276e9&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_wait_event+0xa9/0x290 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81055ab3&amp;gt;&amp;#93;&lt;/span&gt; ? __wake_up+0x53/0x70&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa073171e&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_main+0xace/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730c50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c0ca&amp;gt;&amp;#93;&lt;/span&gt; child_rip+0xa/0x20&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730c50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730c50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c0c0&amp;gt;&amp;#93;&lt;/span&gt; ? child_rip+0x0/0x20&lt;br/&gt;
&amp;lt;4&amp;gt;&lt;br/&gt;
&amp;lt;0&amp;gt;Kernel panic - not syncing: LBUG&lt;br/&gt;
&amp;lt;4&amp;gt;Pid: 6274, comm: mdt01_004 Tainted: G           ---------------  T 2.6.32-358.6.2.el6_lustre.g230b174.x86_64 #1&lt;br/&gt;
&amp;lt;4&amp;gt;Call Trace:&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8150d878&amp;gt;&amp;#93;&lt;/span&gt; ? panic+0xa7/0x16f&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa044beeb&amp;gt;&amp;#93;&lt;/span&gt; ? lbug_with_loc+0x9b/0xb0 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa05b47d6&amp;gt;&amp;#93;&lt;/span&gt; ? linkea_links_find+0x186/0x190 &lt;span class=&quot;error&quot;&gt;&amp;#91;obdclass&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b87206&amp;gt;&amp;#93;&lt;/span&gt; ? mdo_xattr_get+0x26/0x30 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b8a645&amp;gt;&amp;#93;&lt;/span&gt; ? mdd_linkea_prepare+0x95/0x430 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b8ab01&amp;gt;&amp;#93;&lt;/span&gt; ? mdd_links_rename+0x121/0x540 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b8eae6&amp;gt;&amp;#93;&lt;/span&gt; ? mdd_unlink+0xb86/0xe30 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e0db98&amp;gt;&amp;#93;&lt;/span&gt; ? mdo_unlink+0x18/0x50 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e10f40&amp;gt;&amp;#93;&lt;/span&gt; ? mdt_reint_unlink+0x820/0x1010 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e0d891&amp;gt;&amp;#93;&lt;/span&gt; ? mdt_reint_rec+0x41/0xe0 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0df2b03&amp;gt;&amp;#93;&lt;/span&gt; ? mdt_reint_internal+0x4c3/0x780 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0df2e04&amp;gt;&amp;#93;&lt;/span&gt; ? mdt_reint+0x44/0xe0 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0df7ab8&amp;gt;&amp;#93;&lt;/span&gt; ? mdt_handle_common+0x648/0x1660 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e31165&amp;gt;&amp;#93;&lt;/span&gt; ? mds_regular_handle+0x15/0x20 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730388&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_server_handle_request+0x398/0xc60 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa044c5de&amp;gt;&amp;#93;&lt;/span&gt; ? cfs_timer_arm+0xe/0x10 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa045dd8f&amp;gt;&amp;#93;&lt;/span&gt; ? lc_watchdog_touch+0x6f/0x170 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa07276e9&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_wait_event+0xa9/0x290 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81055ab3&amp;gt;&amp;#93;&lt;/span&gt; ? __wake_up+0x53/0x70&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa073171e&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0xace/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730c50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c0ca&amp;gt;&amp;#93;&lt;/span&gt; ? child_rip+0xa/0x20&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730c50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0730c50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c0c0&amp;gt;&amp;#93;&lt;/span&gt; ? child_rip+0x0/0x20&lt;/p&gt;
</description>
                <environment></environment>
        <key id="19435">LU-3474</key>
            <summary>MDS LBUG on unlink?</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="1" iconUrl="https://jira.whamcloud.com/images/icons/priorities/blocker.svg">Blocker</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="bfaccini">Bruno Faccini</assignee>
                                    <reporter username="daire">Daire Byrne</reporter>
                        <labels>
                            <label>mn4</label>
                    </labels>
                <created>Fri, 14 Jun 2013 10:59:54 +0000</created>
                <updated>Thu, 5 Jun 2014 13:09:58 +0000</updated>
                            <resolved>Fri, 19 Jul 2013 16:37:46 +0000</resolved>
                                    <version>Lustre 2.4.0</version>
                    <version>Lustre 2.5.0</version>
                                    <fixVersion>Lustre 2.4.1</fixVersion>
                    <fixVersion>Lustre 2.5.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>16</watches>
                                                                            <comments>
                            <comment id="60653" author="pjones" created="Fri, 14 Jun 2013 14:16:45 +0000"  >&lt;p&gt;Hi Daire&lt;/p&gt;

&lt;p&gt;Good to see you still in the Lustre world!&lt;/p&gt;

&lt;p&gt;Bruno&lt;/p&gt;

&lt;p&gt;Could you please look into this one?&lt;/p&gt;

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

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="60677" author="bfaccini" created="Fri, 14 Jun 2013 16:58:57 +0000"  >&lt;p&gt;Hello Daire,&lt;br/&gt;
Was a crash-dump written during one of the LBUGs ?? Also, has the concerned file-system been formatted in 2.4 or with earlier release (1.8?) ?&lt;/p&gt;</comment>
                            <comment id="60687" author="daire" created="Fri, 14 Jun 2013 17:33:38 +0000"  >&lt;p&gt;Bruno,&lt;/p&gt;

&lt;p&gt;I have a kdump vmcore - it&apos;s too big to attach. I&apos;ve put it in my dropbox account:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://dl.dropboxusercontent.com/u/24821368/vmcore.tgz&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://dl.dropboxusercontent.com/u/24821368/vmcore.tgz&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;The filesystem was formatted using Lustre v2.3.&lt;/p&gt;


&lt;p&gt;Peter,&lt;/p&gt;

&lt;p&gt;Yes it&apos;s been a while! We have actually been using Lustre for a couple of years now at my present company. We are currently building a new filesystem and it seems like about the right time to try out v2. We just need to help you debug it some more like we did at Framestore with v1.8 &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="60703" author="bfaccini" created="Fri, 14 Jun 2013 19:11:44 +0000"  >&lt;p&gt;Thank&apos;s for the crash-dump Daire already! But in order to be able to analyze it I also need the Lustre-modules RPM and the kernel-debuginfo RPM, can you also provide them ??&lt;/p&gt;</comment>
                            <comment id="60706" author="daire" created="Fri, 14 Jun 2013 20:05:32 +0000"  >&lt;p&gt;Bruno,&lt;/p&gt;

&lt;p&gt;We are using the whamcloud binary rpms so you can find them on the download site.&lt;/p&gt;</comment>
                            <comment id="60725" author="prakash" created="Fri, 14 Jun 2013 22:59:35 +0000"  >&lt;p&gt;We&apos;ve also seen this during our recent 2.4-ldiskfs testing at LLNL:&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;LustreError: 7128:0:(linkea.c:169:linkea_links_find()) ASSERTION( ldata-&amp;gt;ld_leh != ((void *)0) ) failed: 
LustreError: 7128:0:(linkea.c:169:linkea_links_find()) LBUG
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&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;crash&amp;gt; bt
PID: 7128   TASK: ffff8805cec96ae0  CPU: 10  COMMAND: &quot;mdt02_034&quot;
 #0 [ffff880605c6b878] machine_kexec at ffffffff81035bfb
 #1 [ffff880605c6b8d8] crash_kexec at ffffffff810c0932
 #2 [ffff880605c6b9a8] panic at ffffffff8150d943
 #3 [ffff880605c6ba28] lbug_with_loc at ffffffffa0646f4b [libcfs]
 #4 [ffff880605c6ba48] linkea_links_find at ffffffffa0838986 [obdclass]
 #5 [ffff880605c6bab8] mdd_linkea_prepare at ffffffffa0d9b645 [mdd]
 #6 [ffff880605c6bb08] mdd_links_rename at ffffffffa0d9bb01 [mdd]
 #7 [ffff880605c6bb88] mdd_unlink at ffffffffa0d9fae6 [mdd]
 #8 [ffff880605c6bc48] mdo_unlink at ffffffffa1009b98 [mdt]
 #9 [ffff880605c6bc58] mdt_reint_unlink at ffffffffa100cf40 [mdt]
#10 [ffff880605c6bcd8] mdt_reint_rec at ffffffffa1009891 [mdt]
#11 [ffff880605c6bcf8] mdt_reint_internal at ffffffffa0feeb03 [mdt]
#12 [ffff880605c6bd38] mdt_reint at ffffffffa0feee04 [mdt]
#13 [ffff880605c6bd58] mdt_handle_common at ffffffffa0ff3ab8 [mdt]
#14 [ffff880605c6bda8] mds_regular_handle at ffffffffa102d155 [mdt]
#15 [ffff880605c6bdb8] ptlrpc_server_handle_request at ffffffffa09b26d8 [ptlrpc]
#16 [ffff880605c6beb8] ptlrpc_main at ffffffffa09b3a6e [ptlrpc]
#17 [ffff880605c6bf48] kernel_thread at ffffffff8100c0ca
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="60773" author="di.wang" created="Mon, 17 Jun 2013 16:56:23 +0000"  >&lt;p&gt;Hmm, apparently in mdd_links_read, it did not check the return value of linkea_init, so the following linked_links_find will deal with the wrong linkea, which cause the panic. Probably this patch should fix it&lt;/p&gt;


&lt;p&gt;diff --git a/lustre/mdd/mdd_dir.c b/lustre/mdd/mdd_dir.c&lt;br/&gt;
index 9f3c333..6435757 100644&lt;br/&gt;
&amp;#8212; a/lustre/mdd/mdd_dir.c&lt;br/&gt;
+++ b/lustre/mdd/mdd_dir.c&lt;br/&gt;
@@ -1075,8 +1075,7 @@ int mdd_links_read(const struct lu_env *env, struct mdd_object *mdd_obj,&lt;br/&gt;
        if (rc &amp;lt; 0)&lt;br/&gt;
                return rc;&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;linkea_init(ldata);&lt;/li&gt;
	&lt;li&gt;return 0;&lt;br/&gt;
+       return linkea_init(ldata);&lt;br/&gt;
 }&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt; /** Read the link EA into a temp buffer.&lt;/p&gt;</comment>
                            <comment id="60775" author="bfaccini" created="Mon, 17 Jun 2013 17:04:11 +0000"  >&lt;p&gt;Thank&apos;s for the direction Di!&lt;br/&gt;
Master patch implementing your proposal is at &lt;a href=&quot;http://review.whamcloud.com/6676&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6676&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="60802" author="daire" created="Tue, 18 Jun 2013 10:46:03 +0000"  >&lt;p&gt;Bruno,&lt;/p&gt;

&lt;p&gt;I can verify the patch stops the LBUG but the syslog gets spammed instead with the likes of:&lt;/p&gt;

&lt;p&gt;Jun 18 11:42:51 bmds1 kernel: LustreError: 24036:0:(mdd_dir.c:995:mdd_links_rename()) link_ea del &apos;from_repo_revision&apos; failed -61 &lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000c68:0x795d:0x0&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jun 18 11:42:52 bmds1 kernel: LustreError: 24005:0:(mdd_dir.c:995:mdd_links_rename()) link_ea del &apos;from_repo_timestamp&apos; failed -61 &lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000c68:0x796c:0x0&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jun 18 11:42:52 bmds1 kernel: LustreError: 24036:0:(mdd_dir.c:995:mdd_links_rename()) link_ea del &apos;checksum_type&apos; failed -61 &lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000c68:0x7941:0x0&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jun 18 11:42:52 bmds1 kernel: LustreError: 24036:0:(mdd_dir.c:995:mdd_links_rename()) link_ea del &apos;from_repo_revision&apos; failed -61 &lt;span class=&quot;error&quot;&gt;&amp;#91;0x200000c68:0x795d:0x0&amp;#93;&lt;/span&gt;&lt;/p&gt;</comment>
                            <comment id="60836" author="bfaccini" created="Tue, 18 Jun 2013 22:07:50 +0000"  >&lt;p&gt;Humm, seems that you trigger cases where the link_ea_header has a NULL leh_reccount !!...&lt;/p&gt;

&lt;p&gt;I will finally need to have a look into earlier crash-dump to see how this can happen.&lt;/p&gt;

&lt;p&gt;You say syslog get spammed, but what does this mean in term of number of msgs per timing window ??&lt;/p&gt;

&lt;p&gt;Also, the names in the msgs you attached are from Yum database and are known to be hard-links to the same inodes, so can you find how-many hard-links concern these FIDs if still present ?&lt;/p&gt;

&lt;p&gt;We may only trigger cases where the reverse link entry was not added in the link_ea because exceeding its maximum ?? And thus the msgs could be avoided ...&lt;/p&gt;
</comment>
                            <comment id="60841" author="di.wang" created="Wed, 19 Jun 2013 02:32:35 +0000"  >&lt;p&gt;Hmm, it seems to me the -ENODATA and ENOENT check is wrong in mdd_links_prepare, which cause mdd_linkea_prepare wrongly return -ENODATA. probably this patch should help.&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;diff --git a/lustre/mdd/mdd_dir.c b/lustre/mdd/mdd_dir.c
index f7947c8..4770c32 100644
--- a/lustre/mdd/mdd_dir.c
+++ b/lustre/mdd/mdd_dir.c
@@ -932,11 +932,10 @@ static int mdd_linkea_prepare(const struct lu_env *env,
        if (oldpfid != NULL) {
                rc = __mdd_links_del(env, mdd_obj, ldata, oldlname, oldpfid);
                if (rc) {
-                       if ((check == 0) ||
-                           (rc != -ENODATA &amp;amp;&amp;amp; rc != -ENOENT))
+                       if ((check == 0 &amp;amp;&amp;amp; (rc == -ENOENT || rc == -ENODATA)))
+                               rc = 0;
+                       else    
                                RETURN(rc);
-                       /* No changes done. */
-                       rc = 0;
                }
        }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="60853" author="daire" created="Wed, 19 Jun 2013 09:48:06 +0000"  >&lt;p&gt;So just to give you an idea of what we are doing here. We are essentially using &quot;rsync --link-dest&quot; to do backups of servers (hence the yum DB files). If the file is unchanged just hardlink it to the previous backup copy. So to trigger these messages we are simply deleting old backups which in many cases simply removes the hard link count by one. This workload has been found to be a good test of metadata and IO. We have never seen this issue in Lustre v1.8 in the 2 years this workload has been running on it.&lt;/p&gt;

&lt;p&gt;In terms of the messages maybe 20/s? It isn&apos;t constant so I guess not all files trigger it. And there can be half an hour between an influx of these messages.&lt;/p&gt;</comment>
                            <comment id="60883" author="spitzcor" created="Wed, 19 Jun 2013 19:55:57 +0000"  >&lt;p&gt;Cray has been seeing this bug a lot.  We&apos;ll try out the patch and report back.  Speak up if you need any of our debug info.&lt;/p&gt;</comment>
                            <comment id="60919" author="amk" created="Thu, 20 Jun 2013 16:08:15 +0000"  >&lt;p&gt;re: &lt;a href=&quot;http://review.whamcloud.com/6676&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6676&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Should mdt_links_read() as well as mdd_links_read() be changed to return the rc from linkea_init()? I&apos;m just noting the symmetry in the code.&lt;/p&gt;</comment>
                            <comment id="60936" author="prakash" created="Thu, 20 Jun 2013 18:04:32 +0000"  >&lt;blockquote&gt;
&lt;p&gt;Should mdt_links_read() as well as mdd_links_read() be changed to return the rc from linkea_init()? I&apos;m just noting the symmetry in the code.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;At first glance it looks like it should. And if it shouldn&apos;t, a comment explaining the difference is needed.&lt;/p&gt;</comment>
                            <comment id="61081" author="bfaccini" created="Mon, 24 Jun 2013 11:23:04 +0000"  >&lt;p&gt;Di,&lt;br/&gt;
Since ENOENT/ENODATA indicate either the link reference was not found in link_ea or there is no more reference at all in link_ea that means the current looked-up entry was never added due to link_ea space exhausted. So yes, seems that the error return value test is wrong (in fact I think in the original version it should have been &quot;(check == 1)&quot; as the 1st condition !!) and that we need to ignore ENOENT/ENODATA and simply continue. BTW, actually the error will only generate the msgs and end-up beeing trashed in mdd_unlink(), with the only side effect of new entry not beeing added upon rename!&lt;/p&gt;

&lt;p&gt;Daire,&lt;br/&gt;
Thank&apos;s for the details on how this happen at your site. The fact you never experienced this with 1.8 is only due to no link_ea there! And as per my last comment just before, even if annoying, the error msgs you now have running with the patch do not indicate something really bad occurs.&lt;/p&gt;

&lt;p&gt;Prakash, Ann, &lt;br/&gt;
I don&apos;t think that mdt_links_read() requires same change like mdd_links_read() because its only caller mdt_path_current() does not use ldata-&amp;gt;ld_leh reference, but anyway I will try to create a reproducer for the situation (no link_ea entry due to overflow/limit?) that triggers the original Assert during unlink() and see if it can also cause problem upon fid2path() lookup.&lt;/p&gt;</comment>
                            <comment id="61307" author="bfaccini" created="Tue, 25 Jun 2013 13:35:27 +0000"  >&lt;p&gt;Just for my understanding and about the reproducer scenario, is it possible that the hard-links beeing removed/unlinked and causing the LBUGs/msgs may have been created when running with some early 2.x version (ie, with more limits in place during link_ea populate) ?&lt;/p&gt;

&lt;p&gt;Patch to be out soon.&lt;/p&gt;
</comment>
                            <comment id="61308" author="daire" created="Tue, 25 Jun 2013 13:38:34 +0000"  >&lt;p&gt;The filesystem was formatted using the latest v2.3 release so many of the hardlinks would have been created under that version.&lt;/p&gt;</comment>
                            <comment id="61310" author="amk" created="Tue, 25 Jun 2013 14:17:46 +0000"  >&lt;p&gt;Cray sees the bug on a file system formatted with 2.4.&lt;/p&gt;</comment>
                            <comment id="61314" author="prakash" created="Tue, 25 Jun 2013 15:14:12 +0000"  >&lt;p&gt;And we have a 2.1 formatted FS upgraded to Lustre 2.4 RPMs.&lt;/p&gt;</comment>
                            <comment id="61322" author="bfaccini" created="Tue, 25 Jun 2013 17:16:50 +0000"  >&lt;p&gt;Just pushed new version/patch-set #2 of change &lt;a href=&quot;http://review.whamcloud.com/6676&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6676&lt;/a&gt;. It adds a few ENODATA error handling fixes, to avoid unnecessary msgs and also prevent early return, to original fix.&lt;/p&gt;

&lt;p&gt;And &lt;a href=&quot;http://review.whamcloud.com/6772&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6772&lt;/a&gt; is cosmetic patch for similar linkea_init() error handling in mdt layer.&lt;/p&gt;</comment>
                            <comment id="61395" author="spitzcor" created="Wed, 26 Jun 2013 17:07:36 +0000"  >&lt;p&gt;Cray testing on change #6676 ps1 and 6772 shows that the changes resolve our problems with the LBUG.&lt;/p&gt;</comment>
                            <comment id="61396" author="bfaccini" created="Wed, 26 Jun 2013 17:47:23 +0000"  >&lt;p&gt;Thank&apos;s for the feed-back Cory, #6676 patch-set #2 should fix the LBUG AND the annoying (and erroneous!) msgs ...&lt;/p&gt;</comment>
                            <comment id="61414" author="spitzcor" created="Wed, 26 Jun 2013 20:53:55 +0000"  >&lt;p&gt;I was mistaken, Cray has not yet tested w/6772 applied.  However, 6676 ps1 did test successfully.&lt;/p&gt;</comment>
                            <comment id="61436" author="dbasabe" created="Thu, 27 Jun 2013 10:28:11 +0000"  >&lt;p&gt;Hello&lt;/p&gt;


&lt;p&gt;In our site, we had this problem with 2.4.50 version. It was produced moving a dir with lots of files to other destination.&lt;/p&gt;

&lt;p&gt;I can confirm that Patch-set #2 has fixed the problem.&lt;/p&gt;</comment>
                            <comment id="61447" author="bfaccini" created="Thu, 27 Jun 2013 13:48:18 +0000"  >&lt;p&gt;Hello Daniel,&lt;br/&gt;
Thank&apos;s for the feed-back too !&lt;br/&gt;
But patch-set #2 was not in accordance with the error reporting rules being used, so I just pushed patch-set #3 to fix that.&lt;/p&gt;</comment>
                            <comment id="61740" author="daire" created="Wed, 3 Jul 2013 11:45:14 +0000"  >&lt;p&gt;I finally got around to testing the two patches - the LBUG has returned. I patched v2.4.0:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;cd /usr/src/lustre-2.4.0/&lt;/li&gt;
	&lt;li&gt;patch -p1 &amp;lt; mdd_dir.c.patch&lt;/li&gt;
	&lt;li&gt;patch -p1 &amp;lt; /tmp/mdt_handler.c.patch&lt;/li&gt;
	&lt;li&gt;./configure&lt;/li&gt;
	&lt;li&gt;make rpms&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Jul  3 12:36:50 bmds1 kernel: LustreError: 13174:0:(linkea.c:169:linkea_links_find()) ASSERTION( ldata-&amp;gt;ld_leh != ((void *)0) ) failed: &lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: LustreError: 13174:0:(linkea.c:169:linkea_links_find()) LBUG&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: Pid: 13174, comm: mdt01_010&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: Call Trace:&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa043c895&amp;gt;&amp;#93;&lt;/span&gt; libcfs_debug_dumpstack+0x55/0x80 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa043ce97&amp;gt;&amp;#93;&lt;/span&gt; lbug_with_loc+0x47/0xb0 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa05a47d6&amp;gt;&amp;#93;&lt;/span&gt; linkea_links_find+0x186/0x190 &lt;span class=&quot;error&quot;&gt;&amp;#91;obdclass&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b65206&amp;gt;&amp;#93;&lt;/span&gt; ? mdo_xattr_get+0x26/0x30 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b68645&amp;gt;&amp;#93;&lt;/span&gt; mdd_linkea_prepare+0x95/0x430 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b68b01&amp;gt;&amp;#93;&lt;/span&gt; mdd_links_rename+0x121/0x520 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0b6cac6&amp;gt;&amp;#93;&lt;/span&gt; mdd_unlink+0xb86/0xe30 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdd&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0dddb88&amp;gt;&amp;#93;&lt;/span&gt; mdo_unlink+0x18/0x50 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0de0f30&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_unlink+0x820/0x1010 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0ddd881&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_rec+0x41/0xe0 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0dc2b03&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_internal+0x4c3/0x780 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0dc2e04&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint+0x44/0xe0 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0dc7ab8&amp;gt;&amp;#93;&lt;/span&gt; mdt_handle_common+0x648/0x1660 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0e01155&amp;gt;&amp;#93;&lt;/span&gt; mds_regular_handle+0x15/0x20 &lt;span class=&quot;error&quot;&gt;&amp;#91;mdt&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa071e388&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_server_handle_request+0x398/0xc60 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa043d5de&amp;gt;&amp;#93;&lt;/span&gt; ? cfs_timer_arm+0xe/0x10 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa044ed8f&amp;gt;&amp;#93;&lt;/span&gt; ? lc_watchdog_touch+0x6f/0x170 &lt;span class=&quot;error&quot;&gt;&amp;#91;libcfs&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa07156e9&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_wait_event+0xa9/0x290 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:50 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81055ab3&amp;gt;&amp;#93;&lt;/span&gt; ? __wake_up+0x53/0x70&lt;br/&gt;
Jul  3 12:36:51 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa071f71e&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_main+0xace/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:51 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa071ec50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:51 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c0ca&amp;gt;&amp;#93;&lt;/span&gt; child_rip+0xa/0x20&lt;br/&gt;
Jul  3 12:36:51 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa071ec50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
Jul  3 12:36:51 bmds1 kernel: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa071ec50&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1700 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;/p&gt;</comment>
                            <comment id="61811" author="bfaccini" created="Thu, 4 Jul 2013 08:20:54 +0000"  >&lt;p&gt;Wow I am sorry Daire, I don&apos;t know how this happen but patch-set#3 of &lt;a href=&quot;http://review.whamcloud.com/6676&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6676&lt;/a&gt; contained a regression from patch-set #1/#2 (in fact it did not contain the main part/change from patch-set #1 that must be in to prevent the LBUG!!) .... Can you give a try to patch-set #4 that should be definitive one ??&lt;/p&gt;</comment>
                            <comment id="62179" author="bfaccini" created="Fri, 12 Jul 2013 13:06:50 +0000"  >&lt;p&gt;Daire, have you been able to test patch-set #4 of &lt;a href=&quot;http://review.whamcloud.com/6676&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6676&lt;/a&gt; finally ??&lt;/p&gt;</comment>
                            <comment id="62384" author="daire" created="Tue, 16 Jul 2013 16:54:19 +0000"  >&lt;p&gt;Bruno,&lt;/p&gt;

&lt;p&gt;I have patched it in and haven&apos;t seen the issue again yet. However I have not had the opportunity to run the same workload (large unlinks) but that should happen between now and next week. I will update if we have any further issues. Thanks for the help.&lt;/p&gt;</comment>
                            <comment id="62392" author="prakash" created="Tue, 16 Jul 2013 17:28:51 +0000"  >&lt;p&gt;FWIW, I&apos;ve applied #6672 and #6676 and have not hit the issue with our test workload (we did hit it repeatedly without #6676).&lt;/p&gt;</comment>
                            <comment id="62631" author="jlevi" created="Fri, 19 Jul 2013 16:37:46 +0000"  >&lt;p&gt;Patch landed to Master. Closing ticket. Please let me know if more work is needed and I will reopen.&lt;/p&gt;</comment>
                            <comment id="85009" author="adilger" created="Wed, 28 May 2014 07:25:17 +0000"  >&lt;p&gt;It seems that  &lt;a href=&quot;http://review.whamcloud.com/6676&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6676&lt;/a&gt; was landed to b2_4 for 2.4.1, but &lt;a href=&quot;http://review.whamcloud.com/6772&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6772&lt;/a&gt; (which was not mentioned anywhere in this bug, but attributed to &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3474&quot; title=&quot;MDS LBUG on unlink?&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3474&quot;&gt;&lt;del&gt;LU-3474&lt;/del&gt;&lt;/a&gt;) was only landed to master for 2.4.52 and not b2_4.  This results in &quot;&lt;tt&gt;lfs fid2path&lt;/tt&gt;&quot; on old IGIF FIDs  with 2.4.2 servers to incorrectly return success if there is no linkEA, but only prints the root path:&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;lfs fid2path /myth [0x10b466:0xfce641b5:0x0]
/myth//
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;There is never a linkEA for  upgraded 1.x files until LFSCK 1.5 is run on a 2.5+ MDS.&lt;/p&gt;</comment>
                            <comment id="85010" author="adilger" created="Wed, 28 May 2014 07:28:30 +0000"  >&lt;p&gt;Cherry-pick &lt;a href=&quot;http://review.whamcloud.com/6772&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/6772&lt;/a&gt; to b2_4: &lt;a href=&quot;http://review.whamcloud.com/10464&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/10464&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="85014" author="bfaccini" created="Wed, 28 May 2014 08:37:25 +0000"  >&lt;p&gt;I think I had mentionned #6772 in this ticket, but anyway I better had, as Di suggested at that time, to merge both patches to avoid such oversight!&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="25027">LU-5145</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </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|hzvte7:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>8703</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>