<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:34:50 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-3544] Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)</title>
                <link>https://jira.whamcloud.com/browse/LU-3544</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;After resolving the issues in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3484&quot; title=&quot;Incorrect identification of anonymous dentry as root under SLES11SP2&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3484&quot;&gt;&lt;del&gt;LU-3484&lt;/del&gt;&lt;/a&gt; and &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3486&quot; title=&quot;LBUG when exporting Lustre 2.4 via NFS on SLES11SP2: ll_dops_init: ASSERTION( de-&amp;gt;d_op == &amp;amp;ll_d_ops ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3486&quot;&gt;&lt;del&gt;LU-3486&lt;/del&gt;&lt;/a&gt;, the testing of exporting NFS over Lustre on SLES11SP2 continues and we hit yet another issue. &lt;/p&gt;

&lt;p&gt;Creating and reading files works fine, but attempting to write to a new file resulted in an ENOENT coming back.&lt;br/&gt;
It&apos;s coming from here:&lt;/p&gt;
&lt;div class=&quot;panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;panelContent&quot;&gt;
&lt;p&gt;00000080:00000001:1.0:1372108818.561839:0:12348:0:(file.c:407:ll_intent_file_open()) Process leaving via out (rc=18446744073709551614 : -2 : 0xfffffffffffffffe)&lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Here&apos;s the line of code:&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;        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (it_disposition(itp, DISP_LOOKUP_NEG))
                 GOTO(out, rc = -ENOENT);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Looking through the DK logs, we noticed something strange. This is the intent open log message for the attempted write:&lt;/p&gt;
&lt;div class=&quot;panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;panelContent&quot;&gt;
&lt;p&gt;00800000:00000002:0.0:1372108818.561125:0:12348:0:(lmv_intent.c:198:lmv_intent_open()) OPEN_INTENT with fid1=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x2000056c1:0x2:0x0&amp;#93;&lt;/span&gt;, fid2=&lt;span class=&quot;error&quot;&gt;&amp;#91;0x2000056c1:0x4:0x0&amp;#93;&lt;/span&gt;, name=&apos;/&apos; -&amp;gt; mds #0&lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Except this write is to a file named something like &apos;myfile&apos;. Specifically, &quot;echo 5 &amp;gt; myfile&quot;.&lt;br/&gt;
Comparing this to the normal case, not exported over NFS, we see the name of the file here like I&apos;d expect.&lt;/p&gt;</description>
                <environment></environment>
        <key id="19654">LU-3544</key>
            <summary>Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)</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="6" iconUrl="https://jira.whamcloud.com/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="laisiyao">Lai Siyao</assignee>
                                    <reporter username="cheng_shao">Cheng Shao</reporter>
                        <labels>
                            <label>patch</label>
                    </labels>
                <created>Mon, 1 Jul 2013 22:53:01 +0000</created>
                <updated>Tue, 27 Jan 2015 02:44:05 +0000</updated>
                            <resolved>Fri, 20 Jun 2014 05:05:07 +0000</resolved>
                                    <version>Lustre 2.4.0</version>
                                    <fixVersion>Lustre 2.6.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>14</watches>
                                                                            <comments>
                            <comment id="61612" author="cheng_shao" created="Mon, 1 Jul 2013 22:58:00 +0000"  >&lt;p&gt;This was caused by the patch introduced by SLES11SP2, the same root cause for in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3484&quot; title=&quot;Incorrect identification of anonymous dentry as root under SLES11SP2&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3484&quot;&gt;&lt;del&gt;LU-3484&lt;/del&gt;&lt;/a&gt; and &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3486&quot; title=&quot;LBUG when exporting Lustre 2.4 via NFS on SLES11SP2: ll_dops_init: ASSERTION( de-&amp;gt;d_op == &amp;amp;ll_d_ops ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3486&quot;&gt;&lt;del&gt;LU-3486&lt;/del&gt;&lt;/a&gt;, wherein the anonymous dentry has name field set to &apos;/&apos; instead of an empty string.&lt;/p&gt;

&lt;p&gt;Patch has been verified to resolve the issue. Will submit for review shortly.&lt;/p&gt;</comment>
                            <comment id="61921" author="cheng_shao" created="Mon, 8 Jul 2013 21:56:07 +0000"  >&lt;p&gt;Patch is up: &lt;a href=&quot;http://review.whamcloud.com/#/c/6920/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/6920/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="62830" author="paf" created="Tue, 23 Jul 2013 17:33:16 +0000"  >&lt;p&gt;This patch causes an interoperability issue between 2.1 servers and 2.4 clients.  &lt;br/&gt;
In particular, the following assertion is triggered during some (fairly heavy) testing at Cray.&lt;/p&gt;

&lt;p&gt;LustreError: 29927:0:(mdt_handler.c:226:mdt_lock_pdo_init()) ASSERTION( namelen &amp;gt; 0 ) failed.&lt;/p&gt;

&lt;p&gt;A look at the 2.4 and 2.1 (using the WC/Intel b2_1 source) code around this assertion, and it seems clear why it works with 2.4.&lt;/p&gt;

&lt;p&gt;Here&apos;s 2.1:&lt;br/&gt;
&#8212;&lt;/p&gt;

&lt;p&gt;if (name != NULL) &lt;/p&gt;
{
                LASSERT(namelen &amp;gt; 0);
                lh-&amp;gt;mlh_pdo_hash = full_name_hash(name, namelen);
        }
&lt;p&gt; else &lt;/p&gt;
{
                LASSERT(namelen == 0);
                lh-&amp;gt;mlh_pdo_hash = 0ull;
        }&lt;br/&gt;
&lt;br/&gt;
&#8212;&lt;br/&gt;
&lt;br/&gt;
Here&apos;s 2.4. The important part is the change to the &apos;if&apos; condition. Ignore the &apos;Workaround for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2856&quot; title=&quot;Kernel panic - not syncing: LBUG - ASSERTION( lh-&amp;gt;mlh_pdo_hash != 0 )&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2856&quot;&gt;&lt;del&gt;LU-2856&lt;/del&gt;&lt;/a&gt;&apos; comment - That&apos;s unrelated.&lt;br/&gt;
&#8212;&lt;br/&gt;
&lt;br/&gt;
if (name != NULL &amp;amp;&amp;amp; (name&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; != &apos;\0&apos;)) {
                LASSERT(namelen &amp;gt; 0);
                lh-&amp;gt;mlh_pdo_hash = full_name_hash(name, namelen);
                /* XXX Workaround for LU-2856
                 * Zero is a valid return value of full_name_hash, but several
                 * users of mlh_pdo_hash assume a non-zero hash value. We
                 * therefore map zero onto an arbitrary, but consistent
                 * value (1) to avoid problems further down the road. */
                if (unlikely(!lh-&amp;gt;mlh_pdo_hash))
                        lh-&amp;gt;mlh_pdo_hash = 1;
        } else {                LASSERT(namelen == 0);                lh-&amp;gt;mlh_pdo_hash = 0ull;        }

&lt;p&gt;&#8212;&lt;/p&gt;

&lt;p&gt;It seems the 2.1 patch should be as simple as replacing &apos;if (name != NULL)&apos; with &apos;if (name != NULL &amp;amp;&amp;amp; (name&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; != &apos;\0&apos;))&apos;, as apparently when the name is not provided from the client, name != NULL, but the first character is not &apos;\0&apos; as expected.&lt;/p&gt;

&lt;p&gt;I will post a patch to b2.1 with this change.&lt;/p&gt;</comment>
                            <comment id="62832" author="bogl" created="Tue, 23 Jul 2013 17:46:42 +0000"  >&lt;p&gt;Patrick,&lt;br/&gt;
 I can see how your proposed patch in b2_1 may fix the interop problem you describe, but are you sure it has no bad side effects when both client and server are 2.1 ?&lt;/p&gt;</comment>
                            <comment id="62834" author="paf" created="Tue, 23 Jul 2013 17:57:30 +0000"  >&lt;p&gt;Bob,&lt;/p&gt;

&lt;p&gt;I&apos;m not entirely certain it doesn&apos;t.  Cray doesn&apos;t run 2.1 clients anywhere, so I&apos;m not well placed to test.  However, it doesn&apos;t seem like it would.  If the first character of a name is null, then it makes sense that the hash would be zero, which is what the change does.&lt;/p&gt;

&lt;p&gt;Separately, Cheng just pointed out that 2.1 does not support the MDS_OPEN_BY_FID flag.&lt;/p&gt;

&lt;p&gt;It appears this flag is only used in ll_intent_file_open.  That&apos;s normally used when exporting via NFS and occasionally otherwise.  &lt;br/&gt;
However, I was able to export NFS from a 2.1 server, so I&apos;m a bit puzzled as to why that worked at all.  I&apos;ll be doing more testing this afternoon and will come back with more data on that.&lt;/p&gt;</comment>
                            <comment id="62850" author="paf" created="Tue, 23 Jul 2013 21:23:35 +0000"  >&lt;p&gt;I&apos;ll need to take a more thorough look at the code to see why, but I wanted to report the results of the testing today.&lt;/p&gt;

&lt;p&gt;I&apos;ve confirmed that despite not supporting the MDS_OPEN_BY_FID flag which is being set by the Lustre client, 2.1 servers are handling NFS exported Lustre just fine.&lt;/p&gt;</comment>
                            <comment id="64431" author="laisiyao" created="Sat, 17 Aug 2013 01:38:05 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3765&quot; title=&quot;2.5.0&amp;lt;-&amp;gt;2.1.5 interop: sanity test 24u: (mdt_handler.c:224:mdt_lock_pdo_init()) ASSERTION( namelen &amp;gt; 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3765&quot;&gt;&lt;del&gt;LU-3765&lt;/del&gt;&lt;/a&gt; is for this interop issue, and I&apos;ve provided a patch which will fix issue on 2.4 code.&lt;/p&gt;</comment>
                            <comment id="64897" author="paf" created="Thu, 22 Aug 2013 21:58:31 +0000"  >&lt;p&gt;This is related to the current discussion on &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3765&quot; title=&quot;2.5.0&amp;lt;-&amp;gt;2.1.5 interop: sanity test 24u: (mdt_handler.c:224:mdt_lock_pdo_init()) ASSERTION( namelen &amp;gt; 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3765&quot;&gt;&lt;del&gt;LU-3765&lt;/del&gt;&lt;/a&gt;.  Note this is currently only for 2.4 servers, but if we want to be interoperable with 2.1 servers by sending the name and length rather than removing the assertion server side, we need to understand why sending the name is negatively affecting 2.4 servers when MDS_OPEN_BY_FID is set.  (Just to be clear for anyone not already familiar:  With 2.4 servers, when MDS_OPEN_BY_FID is set and the name is sent, ENOENT can result incorrectly.  When the name is not sent, this doesn&apos;t happen.)&lt;/p&gt;

&lt;p&gt;If we can fix that, then we can go back to sending name and namelen.&lt;br/&gt;
&amp;#8212;&lt;br/&gt;
I&apos;m trying to understand precisely why sending the name to a server (IE, 2.4) which supports MDS_OPEN_BY_FID leads to the ENOENT. I think it&apos;s coming from somewhere in mdt_reint_open (and/or the call to mdt_open_by_fid_lock in mdt_reint_open). (Specifically, the client will return ENOENT if DISP_LOOKUP_NEG is set by the server.)&lt;/p&gt;

&lt;p&gt;Looking at this particular snippet of code, it seems like the only way DISP_LOOKUP_NEG would get set is if mdt_open_by_fid_lock returns ENOENT (in that case, it&apos;s set in open_by_fid_lock). But I don&apos;t see how that could happen when the dentry name is not null, and not happen when it is. &lt;/p&gt;

&lt;p&gt;Thoughts?&lt;br/&gt;
&#8212;&lt;br/&gt;
} else if ((rr-&amp;gt;rr_namelen == 0 &amp;amp;&amp;amp; create_flags &amp;amp; MDS_OPEN_LOCK) ||&lt;br/&gt;
(create_flags &amp;amp; MDS_OPEN_BY_FID)) &lt;/p&gt;
{ result = mdt_open_by_fid_lock(info, ldlm_rep, lhc); /* If result is 0 then open by FID has found the file * and there is nothing left for us to do here. More * generally if it is anything other than -ENOENT or * -EREMOTE then we return that now. If -ENOENT and * MDS_OPEN_CREAT is set then we must create the file * below. If -EREMOTE then we need to return a LOOKUP * lock to the client, which we do below. Hence this * odd looking condition. See LU-2523. */ if (!(result == -ENOENT &amp;amp;&amp;amp; (create_flags &amp;amp; MDS_OPEN_CREAT)) &amp;amp;&amp;amp; result != -EREMOTE) GOTO(out, result); if (unlikely(rr-&amp;gt;rr_namelen == 0)) GOTO(out, result = -EINVAL); CDEBUG(D_INFO, &quot;No object(2), continue as regular open.\n&quot;); }
&lt;p&gt;&#8212;&lt;/p&gt;</comment>
                            <comment id="64938" author="laisiyao" created="Fri, 23 Aug 2013 04:45:32 +0000"  >&lt;p&gt;Op_by_fid is not clearly defined in lustre code when lu_fid is introduced, and before lu_fid there doesn&apos;t exist s globally unique identifier for a file, so in many operations still supports name after fid failed, this should be a technical debt. I&apos;m planning to clean these code, and after that client request will pack either name or fid (if it&apos;s available), and server will use fid or name only too. This change is a little big, and will take more time.&lt;/p&gt;</comment>
                            <comment id="68023" author="green" created="Tue, 1 Oct 2013 04:41:49 +0000"  >&lt;p&gt;The patch in this ticked was revertd from master due to interop problems described in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3765&quot; title=&quot;2.5.0&amp;lt;-&amp;gt;2.1.5 interop: sanity test 24u: (mdt_handler.c:224:mdt_lock_pdo_init()) ASSERTION( namelen &amp;gt; 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3765&quot;&gt;&lt;del&gt;LU-3765&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="68714" author="paf" created="Wed, 9 Oct 2013 21:35:56 +0000"  >&lt;p&gt;Lai, Peng,&lt;/p&gt;

&lt;p&gt;I understand the goal of recovering the technical debt by cleaning up the MDS_OPEN_BY_FID code and that that is the eventual goal here.&lt;/p&gt;

&lt;p&gt;However:&lt;br/&gt;
If we add support for MDS_OPEN_BY_FID to 2.1 servers, is there any reason we couldn&apos;t go back to not sending the name in ll_intent_file_open? (IE, the &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3544&quot; title=&quot;Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3544&quot;&gt;&lt;del&gt;LU-3544&lt;/del&gt;&lt;/a&gt; patch that was reverted.)  As far as I can see, that would work until the op_by_fid support is completed.&lt;/p&gt;</comment>
                            <comment id="68727" author="laisiyao" created="Thu, 10 Oct 2013 03:46:18 +0000"  >&lt;p&gt;Patrick, yes, the reverted patch could partly work, it&apos;s reverted because the interop test is broken, but we want that always work to prevent new commit to break it silently. I&apos;ll include the change &lt;a href=&quot;http://review.whamcloud.com/#/c/6920/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/6920/&lt;/a&gt; in &lt;a href=&quot;http://review.whamcloud.com/#/c/7476/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/7476/&lt;/a&gt; for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3765&quot; title=&quot;2.5.0&amp;lt;-&amp;gt;2.1.5 interop: sanity test 24u: (mdt_handler.c:224:mdt_lock_pdo_init()) ASSERTION( namelen &amp;gt; 0 ) failed&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3765&quot;&gt;&lt;del&gt;LU-3765&lt;/del&gt;&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="69034" author="jhammond" created="Tue, 15 Oct 2013 21:54:33 +0000"  >&lt;p&gt;In mdt_reint_open() we set DISP_LOOKUP_NEG even when MDS_OPEN_CREAT is used, the create is successful, and 0 is returned.&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;        if (result == -ENOENT || result == -ESTALE) {
        	mdt_set_disposition(info, ldlm_rep, DISP_LOOKUP_NEG);
                if (result == -ESTALE) {
                        /*                                                                          
                         * -ESTALE means the parent is a dead(unlinked) dir, so
                         * it should return -ENOENT to in accordance with the
                         * original mds implementaion.
                         */
                        GOTO(out_parent, result = -ENOENT);
                }
        	if (!(create_flags &amp;amp; MDS_OPEN_CREAT))
                        GOTO(out_parent, result);
                if (exp_connect_flags(req-&amp;gt;rq_export) &amp;amp; OBD_CONNECT_RDONLY)
                        GOTO(out_parent, result = -EROFS);
                *child_fid = *info-&amp;gt;mti_rr.rr_fid2;
                LASSERTF(fid_is_sane(child_fid), &quot;fid=&quot;DFID&quot;\n&quot;,
                         PFID(child_fid));
                /* In the function below, .hs_keycmp resolves to
                 * lu_obj_hop_keycmp() */
                /* coverity[overrun-buffer-val] */
                child = mdt_object_new(info-&amp;gt;mti_env, mdt, child_fid);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Perhaps this issue could be addressed by only returning DISP_LOOKUP_NEG on no create:&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;        if (result == -ENOENT || result == -ESTALE) {
                if (result == -ESTALE) {
                        /*                                                                          
                         * -ESTALE means the parent is a dead(unlinked) dir, so
                         * it should return -ENOENT to in accordance with the
                         * original mds implementaion.
                         */
        	        mdt_set_disposition(info, ldlm_rep, DISP_LOOKUP_NEG);
                        GOTO(out_parent, result = -ENOENT);
        	}

        	if (!(create_flags &amp;amp; MDS_OPEN_CREAT)) {
        	        mdt_set_disposition(info, ldlm_rep, DISP_LOOKUP_NEG);
                        GOTO(out_parent, result);
                }

                if (exp_connect_flags(req-&amp;gt;rq_export) &amp;amp; OBD_CONNECT_RDONLY)
                        GOTO(out_parent, result = -EROFS);

                *child_fid = *info-&amp;gt;mti_rr.rr_fid2;
                LASSERTF(fid_is_sane(child_fid), &quot;fid=&quot;DFID&quot;\n&quot;,
                         PFID(child_fid));
                /* In the function below, .hs_keycmp resolves to
                 * lu_obj_hop_keycmp() */
                /* coverity[overrun-buffer-val] */
                child = mdt_object_new(info-&amp;gt;mti_env, mdt, child_fid);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="69049" author="jhammond" created="Tue, 15 Oct 2013 23:44:47 +0000"  >&lt;p&gt;But I think this would require the clients to change the way they check for stale FID name pairs. In mdc_finish_intent_lock() if M_CHECK_STALE is set then we compare the returned FID to &lt;b&gt;both&lt;/b&gt; op_fid2 and op_fid3. If O_CREATE was set and op_fid3 was stale (because the old file was unlinked) then the logic is a bit off. Since the old FID (op_fid3) is stale but the returned FID is equal to op_fid2. So my the above proposal might fix ll_intent_file_open() at the expense &quot;trying to change FID LBUGs&quot; in ll_update_inode() from ll_revalidate_it(). Bah!&lt;/p&gt;

&lt;p&gt;Also if you&apos;re trying to trace through this then please be aware that mdc_finish_intent_lock() prints op_fid2 twice when it detects a stale FID:&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;                if ((!lu_fid_eq(&amp;amp;op_data-&amp;gt;op_fid2, &amp;amp;mdt_body-&amp;gt;fid1)) &amp;amp;&amp;amp;
                    (!lu_fid_eq(&amp;amp;op_data-&amp;gt;op_fid3, &amp;amp;mdt_body-&amp;gt;fid1))) {
                        CDEBUG(D_DENTRY, &quot;Found stale data &quot;DFID&quot;(&quot;DFID&quot;)/&quot;DFID
                               &quot;\n&quot;, PFID(&amp;amp;op_data-&amp;gt;op_fid2),
                               PFID(&amp;amp;op_data-&amp;gt;op_fid2), PFID(&amp;amp;mdt_body-&amp;gt;fid1));
                        RETURN(-ESTALE);
                }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;(I found that a bit confusing at first.)&lt;/p&gt;</comment>
                            <comment id="69085" author="laisiyao" created="Wed, 16 Oct 2013 08:16:11 +0000"  >&lt;p&gt;Yes, it&apos;s tricky for open by fid if create is set, because you know we have the &quot;trying to change FID LBUG&quot;, so if the file with the specified fid doesn&apos;t exist, we should only create with the old fid (exclusively), but this is also strange, because this doesn&apos;t conform to fid design, and may confuse user space backup tools. So in &lt;a href=&quot;http://review.whamcloud.com/#/c/7476/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/7476/&lt;/a&gt; if open is by fid, it won&apos;t create upon -ENOENT, and per Fan&apos;s suggestion, client should return -ESTALE to not confuse user space application. This may not conform to posix, but it&apos;s the best we can do, the root cause is that revalidate and file open is not atomic.&lt;/p&gt;</comment>
                            <comment id="69109" author="jhammond" created="Wed, 16 Oct 2013 13:32:50 +0000"  >&lt;p&gt;Returning -ENOENT or -ESTALE on open(..., O_CREAT) is not acceptable. We shouldn&apos;t add this breakage to fix NFS export.&lt;/p&gt;</comment>
                            <comment id="69125" author="laisiyao" created="Wed, 16 Oct 2013 15:33:42 +0000"  >&lt;p&gt;Current code can&apos;t handle this either IMHO, either it will return error in M_CHECK_STALE if fid is different from known ones, or it will LBUG in ll_update_inode().&lt;/p&gt;</comment>
                            <comment id="69137" author="jhammond" created="Wed, 16 Oct 2013 16:54:18 +0000"  >&lt;p&gt;As long as the parent exists, the current code does not return -ENOENT or -ESTALE on opens with O_CREAT set.&lt;/p&gt;</comment>
                            <comment id="69166" author="paf" created="Wed, 16 Oct 2013 21:30:29 +0000"  >&lt;p&gt;John,&lt;/p&gt;

&lt;p&gt;With what you&apos;re saying here: &quot;In mdt_reint_open() we set DISP_LOOKUP_NEG even when MDS_OPEN_CREAT is used, the create is successful, and 0 is returned.&quot; &lt;br/&gt;
It sounds like we would expect to see ENOENT on successful O_CREAT requests (when MDS_OPEN_BY_FID is set).&lt;/p&gt;

&lt;p&gt;In other words, we&apos;d expect creating new files in an NFS export from a 2.4 or greater client backed by a 2.4 or greater server to fail with ENOENT.&lt;/p&gt;

&lt;p&gt;Is that correct?  That&apos;s not what we observe.  From reading the code, it seems like that would happen, but we are able to do NFS exports of 2.4 servers from 2.4 clients.  I may have missed something in what you&apos;re saying.  (And I&apos;ve definitely missed something in the code, since it works fine.)&lt;/p&gt;</comment>
                            <comment id="69186" author="laisiyao" created="Thu, 17 Oct 2013 01:56:38 +0000"  >&lt;p&gt;John, could you check ll_intent_file_open -&amp;gt; mdc_intent_lock -&amp;gt; mdc_finish_intent_lock: if file was unlinked and recreated by others (different fid), M_CHECK_STALE will return -ESTALE.&lt;/p&gt;</comment>
                            <comment id="69189" author="jhammond" created="Thu, 17 Oct 2013 02:54:09 +0000"  >&lt;p&gt;Lai I&apos;ve read the same code as you but I don&apos;t think it happens. Can you give me an example where open(..., O_CREAT) returns -ESTALE or -ENOENT?&lt;/p&gt;</comment>
                            <comment id="69195" author="laisiyao" created="Thu, 17 Oct 2013 06:05:44 +0000"  >&lt;p&gt;1. client1 revalidated(IT_OPEN|IT_CREATE) file1 and found open lock cached locally, so it returned successfully.&lt;br/&gt;
2. client2 unlinked file1, which also canceled the open lock on client1.&lt;br/&gt;
3. client2 recreated file1 (with different fid).&lt;br/&gt;
4. client1 opened file1, because it was not opened in revalidate, it called ll_intent_file_open().&lt;br/&gt;
5. mds found file1 (by name), and opened it and replied back.&lt;br/&gt;
6. client1 found fid in the reply was different from old and newly allocated fid, -ESTALE was returned.&lt;/p&gt;
</comment>
                            <comment id="69226" author="jhammond" created="Thu, 17 Oct 2013 16:57:35 +0000"  >&lt;p&gt;Can you create this situation and demonstrate that open(..., O_CREAT) returns -ESTALE or -ENOENT without some trick like deleting the parent directory? With the current master and a RHEL 6.5 (2.6.32-358.18.1.el6.lustre.x86_64) kernel it can&apos;t make it happen. But maybe thing are different on the newer kernel with atomic open support.&lt;/p&gt;</comment>
                            <comment id="69269" author="laisiyao" created="Fri, 18 Oct 2013 01:52:19 +0000"  >&lt;p&gt;I&apos;ll do some test to see the result, btw, could you explain why the above scenario won&apos;t happen? &lt;/p&gt;</comment>
                            <comment id="69272" author="laisiyao" created="Fri, 18 Oct 2013 06:59:29 +0000"  >&lt;p&gt;John, you&apos;re right, this won&apos;t happen on current code because once O_CREAT is set, revalidate will ignore open lock and open on MDS anyway, so in file open, it can always find the opened request from intent. But doesn&apos;t this mean that ll_intent_file_open() will never create file?&lt;/p&gt;</comment>
                            <comment id="73748" author="shadow" created="Wed, 18 Dec 2013 14:27:32 +0000"  >&lt;p&gt;this bug is result of regression introduced by &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-220&quot; title=&quot;renaming the cwd of a process on another client exposes some dcache weirdness&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-220&quot;&gt;&lt;del&gt;LU-220&lt;/del&gt;&lt;/a&gt; and &quot;fix&quot; from &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2523&quot; title=&quot;ll_update_inode()) ASSERTION( lu_fid_eq(&amp;amp;lli-&amp;gt;lli_fid, &amp;amp;body-&amp;gt;fid1) ) failed: Trying to change FID&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2523&quot;&gt;&lt;del&gt;LU-2523&lt;/del&gt;&lt;/a&gt;.&lt;br/&gt;
i think we don&apos;t need an return ESTALE it (but it&apos;s good to prevent panic with update different fid for same object).&lt;/p&gt;

&lt;p&gt;any object is live on FS after unlink until last open closed, so problem now, MDS set a DEAD_OBJ flag for unlinked object but mdd_cd_sanity_check - see that flag and return ENOENT error for orphan object until it&apos;s closed.&lt;br/&gt;
I think, we may revert an &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2523&quot; title=&quot;ll_update_inode()) ASSERTION( lu_fid_eq(&amp;amp;lli-&amp;gt;lli_fid, &amp;amp;body-&amp;gt;fid1) ) failed: Trying to change FID&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2523&quot;&gt;&lt;del&gt;LU-2523&lt;/del&gt;&lt;/a&gt; change and replace with a add additional check for ORPHAN_OBJ to allow operations on orphan objects, anyway we may find that object only by fid, not a by name - so it&apos;s very special operations allowed.&lt;/p&gt;</comment>
                            <comment id="73885" author="jhammond" created="Thu, 19 Dec 2013 20:49:29 +0000"  >&lt;p&gt;Does open create always fail on NFS exports of lustre on SLES11SP2? 3.11 also uses &apos;/&apos; as the name of disconnected dentries from NFS file handle conversion. And I cannot reproduce this issue using Lustre master + patches for 3.11 / 3.11 kernel.&lt;/p&gt;

&lt;p&gt;Alexey, I agree about handling of open unlinked objects (and I look forward to your patches). But I also think my &quot;fix&quot; for &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2523&quot; title=&quot;ll_update_inode()) ASSERTION( lu_fid_eq(&amp;amp;lli-&amp;gt;lli_fid, &amp;amp;body-&amp;gt;fid1) ) failed: Trying to change FID&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2523&quot;&gt;&lt;del&gt;LU-2523&lt;/del&gt;&lt;/a&gt; is correct. Please explain what you dislike about it.&lt;/p&gt;</comment>
                            <comment id="83542" author="jlevi" created="Thu, 8 May 2014 17:27:32 +0000"  >&lt;p&gt;We need the patches that were reverted here to land in 2.6. And we no longer care about 2.1 server compatibility. But when these land we need to ensure they work with 2.4 and 2.5&lt;/p&gt;</comment>
                            <comment id="83606" author="laisiyao" created="Fri, 9 May 2014 06:07:51 +0000"  >&lt;p&gt;I&apos;ll update &lt;a href=&quot;http://review.whamcloud.com/#/c/7476/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/7476/&lt;/a&gt; soon.&lt;/p&gt;</comment>
                            <comment id="86151" author="paf" created="Mon, 9 Jun 2014 20:27:23 +0000"  >&lt;p&gt;From testing of patch set 20:&lt;/p&gt;

&lt;p&gt;During Cray testing of NFS export from a SLES11SP3 client with this patch (client+server), I hit the assertion below on MDS0 (which has MDTs 0 and 1 on it). Ran a modified racer against the NFS export and an unmodified racer on a Lustre 2.5.58 client.&lt;/p&gt;

&lt;p&gt;Dump of MDS0 is up at:&lt;br/&gt;
ftp.whamcloud.com/uploads/&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3544&quot; title=&quot;Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3544&quot;&gt;&lt;del&gt;LU-3544&lt;/del&gt;&lt;/a&gt;/&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3544&quot; title=&quot;Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3544&quot;&gt;&lt;del&gt;LU-3544&lt;/del&gt;&lt;/a&gt;_140609.tar.gz&lt;/p&gt;

&lt;p&gt;&amp;lt;6&amp;gt;Lustre: Skipped 1 previous similar message&lt;br/&gt;
&amp;lt;3&amp;gt;LustreError: 7816:0:(mdt_reint.c:1519:mdt_reint_migrate_internal()) centssm2-MDT0000: parent &lt;span class=&quot;error&quot;&gt;&amp;#91;0x400000400:0x1:0x0&amp;#93;&lt;/span&gt; is still on the same MDT, which should be migrated first: rc = -1&lt;br/&gt;
&amp;lt;3&amp;gt;LustreError: 7816:0:(mdt_reint.c:1519:mdt_reint_migrate_internal()) Skipped 3 previous similar messages&lt;br/&gt;
&amp;lt;3&amp;gt;LustreError: 7298:0:(mdd_dir.c:3957:mdd_migrate()) centssm2-MDD0000: &lt;span class=&quot;error&quot;&gt;&amp;#91;0x400000401:0x330f:0x0&amp;#93;&lt;/span&gt;8 is already opened count 1: rc = -16&lt;br/&gt;
&amp;lt;0&amp;gt;LustreError: 7816:0:(service.c:193:ptlrpc_save_lock()) ASSERTION( rs-&amp;gt;rs_nlocks &amp;lt; 8 ) failed:&lt;br/&gt;
&amp;lt;0&amp;gt;LustreError: 7816:0:(service.c:193:ptlrpc_save_lock()) LBUG&lt;br/&gt;
&amp;lt;4&amp;gt;Pid: 7816, comm: mdt00_007&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;ffffffffa0b27895&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;ffffffffa0b27e97&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;ffffffffa0ebd656&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_save_lock+0xb6/0xf0 &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;ffffffffa15b074b&amp;gt;&amp;#93;&lt;/span&gt; mdt_save_lock+0x22b/0x320 &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;ffffffffa15b089c&amp;gt;&amp;#93;&lt;/span&gt; mdt_object_unlock+0x5c/0x160 &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;ffffffffa15b2187&amp;gt;&amp;#93;&lt;/span&gt; mdt_object_unlock_put+0x17/0x110 &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;ffffffffa15cf18d&amp;gt;&amp;#93;&lt;/span&gt; mdt_unlock_list+0x5d/0x1e0 &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;ffffffffa15d1e7c&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_migrate_internal+0x109c/0x1b50 &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;ffffffffa15d6113&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_rename_or_migrate+0x2a3/0x660 &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;ffffffffa0e8abc0&amp;gt;&amp;#93;&lt;/span&gt; ? ldlm_blocking_ast+0x0/0x180 &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;ffffffffa0e8c230&amp;gt;&amp;#93;&lt;/span&gt; ? ldlm_completion_ast+0x0/0x930 &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;ffffffffa15d64e3&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_migrate+0x13/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;ffffffffa15cea81&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;ffffffffa15b3e93&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint_internal+0x4c3/0x7c0 &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;ffffffffa15b471b&amp;gt;&amp;#93;&lt;/span&gt; mdt_reint+0x6b/0x120 &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;ffffffffa0f182ac&amp;gt;&amp;#93;&lt;/span&gt; tgt_request_handle+0x23c/0xac0 &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;ffffffffa0ec7d1a&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_main+0xd1a/0x1980 &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;ffffffff810096f0&amp;gt;&amp;#93;&lt;/span&gt; ? __switch_to+0xd0/0x320&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81528090&amp;gt;&amp;#93;&lt;/span&gt; ? thread_return+0x4e/0x76e&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa0ec7000&amp;gt;&amp;#93;&lt;/span&gt; ? ptlrpc_main+0x0/0x1980 &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;ffffffff8109aee6&amp;gt;&amp;#93;&lt;/span&gt; kthread+0x96/0xa0&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c20a&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;ffffffff8109ae50&amp;gt;&amp;#93;&lt;/span&gt; ? kthread+0x0/0xa0&lt;br/&gt;
&amp;lt;4&amp;gt; &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8100c200&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: 7816, comm: mdt00_007 Not tainted 2.6.32.431.5.1.el6_lustre #1&lt;/p&gt;
</comment>
                            <comment id="86399" author="laisiyao" created="Thu, 12 Jun 2014 02:32:10 +0000"  >&lt;p&gt;Patrick, the racer issue is DNE NFS reexport issue, which was not full tested, could you create a new ticket to track there (you can assign to me)?&lt;/p&gt;</comment>
                            <comment id="86400" author="laisiyao" created="Thu, 12 Jun 2014 02:34:37 +0000"  >&lt;p&gt;In Parallel-scale-nfs test 2 new issues are found, so now there are 3 patches in total:&lt;br/&gt;
&lt;a href=&quot;http://review.whamcloud.com/#/c/7476/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/7476/&lt;/a&gt;&lt;br/&gt;
&lt;a href=&quot;http://review.whamcloud.com/#/c/10692/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/10692/&lt;/a&gt;&lt;br/&gt;
&lt;a href=&quot;http://review.whamcloud.com/#/c/10693/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/10693/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="87132" author="pjones" created="Fri, 20 Jun 2014 05:05:07 +0000"  >&lt;p&gt;Landed for 2.6&lt;/p&gt;</comment>
                            <comment id="87261" author="laisiyao" created="Mon, 23 Jun 2014 03:28:13 +0000"  >&lt;p&gt;parallel-scale-nfsv3 iorssf still failed, and it should be the same issue as &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-1639&quot; title=&quot;Test failure parallel-scale-nfsv3, test_iorssf&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-1639&quot;&gt;LU-1639&lt;/a&gt;, which is a kernel nfs issue.&lt;/p&gt;</comment>
                            <comment id="87262" author="laisiyao" created="Mon, 23 Jun 2014 03:28:38 +0000"  >&lt;p&gt;All required patches are landed.&lt;/p&gt;</comment>
                            <comment id="100802" author="gerrit" created="Fri, 5 Dec 2014 06:58:34 +0000"  >&lt;p&gt;Lai Siyao (lai.siyao@intel.com) uploaded a new patch: &lt;a href=&quot;http://review.whamcloud.com/12952&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/12952&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3544&quot; title=&quot;Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3544&quot;&gt;&lt;del&gt;LU-3544&lt;/del&gt;&lt;/a&gt; xattr: xattr data may be gone with lock held&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: b2_5&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: e057a284afb2020681868f538934a839b2649c99&lt;/p&gt;</comment>
                            <comment id="104804" author="gerrit" created="Tue, 27 Jan 2015 02:44:05 +0000"  >&lt;p&gt;Oleg Drokin (oleg.drokin@intel.com) merged in patch &lt;a href=&quot;http://review.whamcloud.com/12952/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/12952/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-3544&quot; title=&quot;Writing to new files under NFS export from Lustre will result in ENOENT (SLES11SP2)&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-3544&quot;&gt;&lt;del&gt;LU-3544&lt;/del&gt;&lt;/a&gt; xattr: xattr data may be gone with lock held&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: b2_5&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: fe9ad627b6d83e29039c0c6c0b555aae5f23e9a7&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="20358">LU-3765</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="24836">LU-5109</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25113">LU-5177</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|hzvuif:</customfieldvalue>

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