<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:48:22 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-11952] open+create resend can recreate a file after unlink</title>
                <link>https://jira.whamcloud.com/browse/LU-11952</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;While testing a &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11444&quot; title=&quot;RPC resend may corrupt the data&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11444&quot;&gt;&lt;del&gt;LU-11444&lt;/del&gt;&lt;/a&gt; with a racer, we found a crash related to the assert in this patch.&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;[  365.369900] Kernel panic - not syncing: LBUG
[  365.369902] CPU: 1 PID: 11263 Comm: mdt00_026 Tainted: G           OE  ------------   3.10.0-327.36.3.x3.0.22.x86_64 #1
[  365.369903] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[  365.369906]  ffffffffa04d7a03 00000000df5aaa35 ffff880099457530 ffffffff81634b81
[  365.369908]  ffff8800994575b0 ffffffff8162e410 ffffffff00000008 ffff8800994575c0
[  365.369909]  ffff880099457560 00000000df5aaa35 ffffffffa08ed140 ffffffffa04e2525
[  365.369910] Call Trace:
[  365.369914]  [&amp;lt;ffffffff81634b81&amp;gt;] dump_stack+0x19/0x1b
[  365.369916]  [&amp;lt;ffffffff8162e410&amp;gt;] panic+0xd8/0x1e7
[  365.369924]  [&amp;lt;ffffffffa04b6013&amp;gt;] lbug_with_loc+0xb3/0xc0 [libcfs]
[  365.369968]  [&amp;lt;ffffffffa08b69a7&amp;gt;] tgt_add_reply_data+0x217/0x220 [ptlrpc]
[  365.370003]  [&amp;lt;ffffffffa08b8bc2&amp;gt;] tgt_last_rcvd_update+0x742/0xe40 [ptlrpc]
[  365.370036]  [&amp;lt;ffffffffa08bda82&amp;gt;] tgt_txn_stop_cb+0x1a2/0x4a0 [ptlrpc]
[  365.370045]  [&amp;lt;ffffffffa0a88b18&amp;gt;] ? osd_attr_set+0x218/0x960 [osd_ldiskfs]
[  365.370066]  [&amp;lt;ffffffffa05ebc43&amp;gt;] dt_txn_hook_stop+0x63/0x80 [obdclass]
[  365.370076]  [&amp;lt;ffffffffa0a8a5fd&amp;gt;] osd_trans_stop+0x12d/0x430 [osd_ldiskfs]
[  365.370096]  [&amp;lt;ffffffffa060993e&amp;gt;] ? lu_ucred+0x1e/0x30 [obdclass]
[  365.370104]  [&amp;lt;ffffffffa0d9eace&amp;gt;] ? mdd_changelog_ns_store+0x2e/0x650 [mdd]
[  365.370111]  [&amp;lt;ffffffffa0d325a2&amp;gt;] lod_trans_stop+0x52/0x890 [lod]
[  365.370118]  [&amp;lt;ffffffffa0dbc270&amp;gt;] mdd_trans_stop+0x20/0x34 [mdd]
[  365.370125]  [&amp;lt;ffffffffa0da6225&amp;gt;] mdd_create+0x1075/0x12a0 [mdd]
[  365.370138]  [&amp;lt;ffffffffa0c79062&amp;gt;] mdt_reint_open+0x1f92/0x2e00 [mdt]
[  365.370167]  [&amp;lt;ffffffffa0857da0&amp;gt;] ? lustre_msg_buf_v2+0x1b0/0x1b0 [ptlrpc]
[  365.370179]  [&amp;lt;ffffffffa0c7a48d&amp;gt;] mdt_reconstruct_open+0x5bd/0xb80 [mdt]
[  365.370192]  [&amp;lt;ffffffffa0c7025c&amp;gt;] mdt_reconstruct+0x4c/0x160 [mdt]
[  365.370204]  [&amp;lt;ffffffffa0c4cbd8&amp;gt;] mdt_reint_internal+0x998/0xb30 [mdt]
[  365.370213]  [&amp;lt;ffffffffa0c4ced2&amp;gt;] mdt_intent_reint+0x162/0x420 [mdt]
[  365.370222]  [&amp;lt;ffffffffa0c508f5&amp;gt;] mdt_intent_opc+0x215/0xb30 [mdt]
[  365.370258]  [&amp;lt;ffffffffa085c480&amp;gt;] ? lustre_swab_ldlm_policy_data+0x30/0x30 [ptlrpc]
[  365.370268]  [&amp;lt;ffffffffa0c58668&amp;gt;] mdt_intent_policy+0x138/0x320 [mdt]
[  365.370298]  [&amp;lt;ffffffffa0807373&amp;gt;] ldlm_lock_enqueue+0x343/0xae0 [ptlrpc]
[  365.370307]  [&amp;lt;ffffffffa04c9cc0&amp;gt;] ? cfs_hash_lookup+0x90/0xc0 [libcfs]
[  365.370339]  [&amp;lt;ffffffffa082ef23&amp;gt;] ldlm_handle_enqueue0+0x9c3/0x1840 [ptlrpc]
[  365.370375]  [&amp;lt;ffffffffa085c500&amp;gt;] ? lustre_swab_ldlm_lock_desc+0x30/0x30 [ptlrpc]
[  365.370411]  [&amp;lt;ffffffffa08c0cd2&amp;gt;] tgt_enqueue+0x62/0x210 [ptlrpc]
[  365.370443]  [&amp;lt;ffffffffa08c59e9&amp;gt;] tgt_request_handle+0x949/0x1240 [ptlrpc]
[  365.370480]  [&amp;lt;ffffffffa08676cb&amp;gt;] ptlrpc_server_handle_request+0x21b/0xa90 [ptlrpc]
[  365.370519]  [&amp;lt;ffffffffa0864fa5&amp;gt;] ? ptlrpc_wait_event+0xa5/0x350 [ptlrpc]
[  365.370549]  [&amp;lt;ffffffffa086b00e&amp;gt;] ptlrpc_main+0xc1e/0x2300 [ptlrpc]
[  365.370551]  [&amp;lt;ffffffff810c22ee&amp;gt;] ? dequeue_task_fair+0x42e/0x640
[  365.370553]  [&amp;lt;ffffffff810bb7d5&amp;gt;] ? sched_clock_cpu+0x85/0xc0
[  365.370588]  [&amp;lt;ffffffffa086a3f0&amp;gt;] ? ptlrpc_register_service+0x1070/0x1070 [ptlrpc]
[  365.370590]  [&amp;lt;ffffffff810a5b8f&amp;gt;] kthread+0xcf/0xe0
[  365.370593]  [&amp;lt;ffffffff810a5ac0&amp;gt;] ? kthread_create_on_node+0x140/0x140
[  365.370595]  [&amp;lt;ffffffff81644fd8&amp;gt;] ret_from_fork+0x58/0x90
[  365.370597]  [&amp;lt;ffffffff810a5ac0&amp;gt;] ? kthread_create_on_node+0x140/0x140
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;This assert have checked we have no xid step down for the slot.&lt;/p&gt;

&lt;p&gt;Original idea was regression from a patch, but later we have decided it&apos;s bug in open replay code. Bug looks addressed to the valid situation when object may don&apos;t &apos;exist&apos; or object fid is different than client requested.&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; (mdt_get_disposition(ldlm_rep, DISP_OPEN_CREATE)) {
                struct obd_export *exp = req-&amp;gt;rq_export;
                /*
                 * We failed after creation, but we &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt; not know in which step
                 * we failed. So &lt;span class=&quot;code-keyword&quot;&gt;try&lt;/span&gt; to check the child object.
                 */
                parent = mdt_object_find(env, mdt, rr-&amp;gt;rr_fid1);
                &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (IS_ERR(parent)) {
                        rc = PTR_ERR(parent);
                        LCONSOLE_WARN(&lt;span class=&quot;code-quote&quot;&gt;&quot;Parent &quot;&lt;/span&gt;DFID&lt;span class=&quot;code-quote&quot;&gt;&quot; lookup error %d.&quot;&lt;/span&gt;
                                      &lt;span class=&quot;code-quote&quot;&gt;&quot; Evicting client %s with export %s.\n&quot;&lt;/span&gt;,
                                      PFID(rr-&amp;gt;rr_fid1), rc,
                                      obd_uuid2str(&amp;amp;exp-&amp;gt;exp_client_uuid),
                                      obd_export_nid2str(exp));
                        mdt_export_evict(exp);
                        RETURN_EXIT;
                }

                child = mdt_object_find(env, mdt, rr-&amp;gt;rr_fid2);
                &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (IS_ERR(child)) {
                        rc = PTR_ERR(child);
                        LCONSOLE_WARN(&lt;span class=&quot;code-quote&quot;&gt;&quot;cannot lookup child &quot;&lt;/span&gt;DFID&lt;span class=&quot;code-quote&quot;&gt;&quot;: rc = %d; &quot;&lt;/span&gt;
                                      &lt;span class=&quot;code-quote&quot;&gt;&quot;evicting client %s with export %s\n&quot;&lt;/span&gt;,
                                      PFID(rr-&amp;gt;rr_fid2), rc,
                                      obd_uuid2str(&amp;amp;exp-&amp;gt;exp_client_uuid),
                                      obd_export_nid2str(exp));
                        mdt_object_put(env, parent);
                        mdt_export_evict(exp);
                        RETURN_EXIT;
                }

                &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (unlikely(mdt_object_remote(child))) {
                        &lt;span class=&quot;code-comment&quot;&gt;/* the child object was created on remote server */&lt;/span&gt;
                        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (!mdt_is_dne_client(exp)) {
                                &lt;span class=&quot;code-comment&quot;&gt;/* Return -EIO &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; old client */&lt;/span&gt;
                                mdt_object_put(env, parent);
                                mdt_object_put(env, child);
                                GOTO(out, rc = -EIO);
                        }
                        repbody-&amp;gt;mbo_fid1 = *rr-&amp;gt;rr_fid2;
                        repbody-&amp;gt;mbo_valid |= (OBD_MD_FLID | OBD_MD_MDS);
                        rc = 0;
                } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (mdt_object_exists(child)) {
                                mdt_prep_ma_buf_from_rep(info, child, ma);
                                rc = mdt_attr_get_complex(info, child, ma);
                                &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (rc == 0)
                                        rc = mdt_finish_open(info, parent,
                                                             child, open_flags,
                                                             1, ldlm_rep);
                        } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                                /* the child does not exist, we should &lt;span class=&quot;code-keyword&quot;&gt;do&lt;/span&gt;
                                 * regular open */
                                mdt_object_put(env, parent);
                                mdt_object_put(env, child);
                                GOTO(regular_open, 0); &amp;lt;&amp;lt;&amp;lt;
                        }
                }
                mdt_object_put(env, parent);
                mdt_object_put(env, child);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;


&lt;p&gt;operation order restored from requests history hash &lt;br/&gt;
1) fileA created from client 1&lt;br/&gt;
2) fileA open(O_CREATE) from client 2&lt;br/&gt;
3) link to the client2 failed before reply send (from client view)&lt;br/&gt;
4) unlink(fileA) from client1, it have blocked until reply arrived to the client2&lt;br/&gt;
5) client2 started to resend a open(O_CREATE)&lt;br/&gt;
6) unlink(fileA) was finished&lt;br/&gt;
&amp;#8211; it looks lu_site cache remove this object from cache in this time.&lt;br/&gt;
7) resend handled by MDT and found request-&amp;gt;fid2 isn&apos;t exist, so full create needs.&lt;/p&gt;

&lt;p&gt;---- thats all.&lt;/p&gt;

&lt;p&gt;variant of this case.&lt;/p&gt;

&lt;p&gt;a) without unlink - p.2 need to found an object by name and reply with different fid, so resend will don&apos;t found a child by fid2 from request (object created without LOHA_EXIST)&lt;/p&gt;</description>
                <environment></environment>
        <key id="54844">LU-11952</key>
            <summary>open+create resend can recreate a file after unlink</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="2" iconUrl="https://jira.whamcloud.com/images/icons/priorities/critical.svg">Critical</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="askulysh">Andriy Skulysh</assignee>
                                    <reporter username="shadow">Alexey Lyashkov</reporter>
                        <labels>
                            <label>patch</label>
                    </labels>
                <created>Mon, 11 Feb 2019 10:00:49 +0000</created>
                <updated>Mon, 13 Dec 2021 15:11:51 +0000</updated>
                            <resolved>Mon, 13 Dec 2021 15:11:51 +0000</resolved>
                                    <version>Lustre 2.10.0</version>
                    <version>Lustre 2.11.0</version>
                    <version>Lustre 2.12.0</version>
                                    <fixVersion>Lustre 2.15.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>8</watches>
                                                                            <comments>
                            <comment id="241715" author="bzzz" created="Mon, 11 Feb 2019 15:39:19 +0000"  >&lt;p&gt;if fileA was opened (i.e. step 2 were executed except successful reply), then opencount is non-zero and unlink can&apos;t destroy the object.&lt;br/&gt;
at the moment I don&apos;t understand how opencount can get to 0 unless client2 is evicted.&lt;/p&gt;</comment>
                            <comment id="241717" author="bzzz" created="Mon, 11 Feb 2019 16:15:09 +0000"  >&lt;p&gt;forgot to mention, that open normally stores FID in last_rcvd so that reconstruct can find the object w/o name. IIRC &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/smile.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="241720" author="tappro" created="Mon, 11 Feb 2019 16:55:05 +0000"  >&lt;p&gt;Alex, I think the opened file is still open-unlinked but its FID is FID1 from create at step 1, while resend is made with FID2 from client2. At step 2 it found file by name and open it (its FID is FID1) but during resend name doesn&apos;t exist and new file is created with the same name and FID2. It looks like possible case but I don&apos;t see why this is critical error after all, that is valid race, how is it different from the case when unlink from client 1 comes earlier than open from client2? &lt;/p&gt;</comment>
                            <comment id="241722" author="shadow" created="Mon, 11 Feb 2019 17:03:37 +0000"  >&lt;p&gt;Alex, reconstruct open isn&apos;t take any fid&apos;s from last_rcvd and don&apos;t store anything except a disposition.&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;
struct lsd_reply_data {
        __u64 lrd_transno;      &lt;span class=&quot;code-comment&quot;&gt;/* transaction number */&lt;/span&gt;
        __u64 lrd_xid;          &lt;span class=&quot;code-comment&quot;&gt;/* transmission id */&lt;/span&gt;
        __u64 lrd_data;         &lt;span class=&quot;code-comment&quot;&gt;/* per-operation data */&lt;/span&gt;
        __u32 lrd_result;       &lt;span class=&quot;code-comment&quot;&gt;/* request result */&lt;/span&gt;
        __u32 lrd_client_gen;   &lt;span class=&quot;code-comment&quot;&gt;/* client generation */&lt;/span&gt;
};
struct tg_reply_data {
        &lt;span class=&quot;code-comment&quot;&gt;/** chain of reply data anchored in tg_export_data */&lt;/span&gt;
        struct list_head        trd_list;
        &lt;span class=&quot;code-comment&quot;&gt;/** copy of on-disk reply data */&lt;/span&gt;
        struct lsd_reply_data   trd_reply;
        &lt;span class=&quot;code-comment&quot;&gt;/** versions &lt;span class=&quot;code-keyword&quot;&gt;for&lt;/span&gt; Version Based Recovery */&lt;/span&gt;
        __u64                   trd_pre_versions[4];
        &lt;span class=&quot;code-comment&quot;&gt;/** slot index in reply_data file */&lt;/span&gt;
        &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;                     trd_index;
        &lt;span class=&quot;code-comment&quot;&gt;/** tag the client used */&lt;/span&gt;
        __u16                   trd_tag;
};
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;it will be best solution in case if reply cache will store an open handle and file xid, but nothing now.&lt;/p&gt;</comment>
                            <comment id="241723" author="shadow" created="Mon, 11 Feb 2019 17:15:12 +0000"  >&lt;p&gt;Mikhail it&apos;s problem from recovery view and execute-once semantic. As different result will be in case fail hit and don&apos;t hit between unlink and resend. &lt;br/&gt;
object will created in case fail don&apos;t hit, but if crash it exist we don&apos;t have an object created. because create request can removed from replay queue due commit update and don&apos;t join into recovery. So it&apos;s not a valid race I think.&lt;br/&gt;
MDT have create an object when none expect to have this reply.&lt;/p&gt;</comment>
                            <comment id="241724" author="bzzz" created="Mon, 11 Feb 2019 17:15:33 +0000"  >&lt;p&gt;sure, I don&apos;t recall all the details, but we do have XID in mfd:&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;
struct mdt_file_data {
	&lt;span class=&quot;code-comment&quot;&gt;/**  portals handle must be first */&lt;/span&gt;
	struct portals_handle	mfd_open_handle;
	&lt;span class=&quot;code-comment&quot;&gt;/** open mode provided by client */&lt;/span&gt;
	u64			mfd_open_flags;
	&lt;span class=&quot;code-comment&quot;&gt;/** &lt;span class=&quot;code-keyword&quot;&gt;protected&lt;/span&gt; by med_open_lock */&lt;/span&gt;
	struct list_head	mfd_list;
	&lt;span class=&quot;code-comment&quot;&gt;/** xid of the open request */&lt;/span&gt;
	__u64			mfd_xid;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;which should be enough to find the object and reconstruct the reply?&lt;/p&gt;</comment>
                            <comment id="241730" author="shadow" created="Mon, 11 Feb 2019 18:11:57 +0000"  >&lt;p&gt;Alex, current code have mfd search too later after req-&amp;gt;r_fid2 checks. It&apos;s problem. As about solution, same way was chosen but several problems exist.&lt;br/&gt;
1) mfd was don&apos;t exist with resend after recovery. if no open lock provided. client start create before fail, mdt failed before reply send. Client have think this is resend but oops. But say way will be in case client able to close this file in situation.&lt;br/&gt;
client doing open, link fail, client have resend a open and send close immediately. But server able to delivery a reply (server don&apos;t know about link flap, it&apos;s just client side view). Reply arrived to the same open request as XID isn&apos;t changed.&lt;br/&gt;
Based on LNet ideas - we should don&apos;t have assumptions about request order processing - so processing close before open resend is possible. mfd will destroyed in this case.. OOPS.&lt;br/&gt;
so we need to separate mfd close vs mfd don&apos;t created.&lt;/p&gt;

&lt;p&gt;2) mfd list is large in most cases, scanning this list can take a lot time a specially if it twice (second one in mdt_finish_open).&lt;/p&gt;

&lt;p&gt;3) I worry about remote create in open(O_CREATE) case - what we should do in this case? did it possible to return different fid as provided as fid2 in client open?&lt;/p&gt;

&lt;p&gt;as about 1/2 it looks solution exist. tg_reply_data is completely &apos;in memory&apos; object so easy to extent to the two additional fid.&lt;br/&gt;
first one - mfd_exist, should resolve a problem with (1) and separate resend after replay (should be handled as replay) and clear resend.&lt;br/&gt;
second one - open handle - support to fast search mfd via mdt_handle2mfd.&lt;/p&gt;

&lt;p&gt;(several hack&apos;s / optimisations possible - as open is schedule difficult reply always so we able to separate reply is delivered or not in mdt_steal_locks which scan for outstanding difficult reply&apos;s)&lt;/p&gt;</comment>
                            <comment id="241764" author="shadow" created="Tue, 12 Feb 2019 08:52:38 +0000"  >&lt;p&gt;cross open(O_CREATE) don&apos;t have mfd also, it have create an object on remote mdt but no MFD was created in same time (mdt_finish_open skip).&lt;/p&gt;

&lt;p&gt;So good to save a real child fid in this case to avoid lookup by name and side effects of this change.&lt;/p&gt;</comment>
                            <comment id="242077" author="gerrit" created="Fri, 15 Feb 2019 15:38:47 +0000"  >&lt;p&gt;&lt;del&gt;Alexey Lyashkov (c17817@cray.com) uploaded a new patch:&lt;/del&gt;&lt;br/&gt;
&lt;a href=&quot;https://review.whamcloud.com/34266-&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/34266&lt;/a&gt;&lt;br/&gt;
 &lt;del&gt;Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11952&quot; title=&quot;open+create resend can recreate a file after unlink&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11952&quot;&gt;&lt;del&gt;LU-11952&lt;/del&gt;&lt;/a&gt; mdt: fix reconstruct_open&lt;/del&gt;&lt;br/&gt;
 &lt;del&gt;Project: fs/lustre-release&lt;/del&gt;&lt;br/&gt;
 &lt;del&gt;Branch: master&lt;/del&gt;&lt;br/&gt;
 &lt;del&gt;Current Patch Set: 1&lt;/del&gt;&lt;br/&gt;
 &lt;del&gt;Commit: 02ff43d8954460d43228fd866c274fdda81bfdc6&lt;/del&gt;&lt;/p&gt;</comment>
                            <comment id="248816" author="gerrit" created="Sun, 9 Jun 2019 10:17:52 +0000"  >&lt;p&gt;Andriy Skulysh (c17819@cray.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/35112&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/35112&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11952&quot; title=&quot;open+create resend can recreate a file after unlink&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11952&quot;&gt;&lt;del&gt;LU-11952&lt;/del&gt;&lt;/a&gt; mdt: fix reconstruct open&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: c0d28df84c5b946e1f8f35134a78b6e567ef5e15&lt;/p&gt;</comment>
                            <comment id="256710" author="spitzcor" created="Sun, 20 Oct 2019 23:07:12 +0000"  >&lt;p&gt;I understand that &lt;a href=&quot;https://review.whamcloud.com/35112&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/35112&lt;/a&gt; is moving slowly, but it should be considered for L2.13 if at all possible.&lt;/p&gt;</comment>
                            <comment id="264109" author="spitzcor" created="Wed, 26 Feb 2020 20:19:03 +0000"  >&lt;p&gt;I guess we can shoot for 2.14.0 now.&lt;/p&gt;</comment>
                            <comment id="296803" author="spitzcor" created="Fri, 26 Mar 2021 02:45:48 +0000"  >&lt;p&gt;2.15.0?&lt;/p&gt;</comment>
                            <comment id="320705" author="gerrit" created="Mon, 13 Dec 2021 03:51:54 +0000"  >&lt;p&gt;&quot;Oleg Drokin &amp;lt;green@whamcloud.com&amp;gt;&quot; merged in patch &lt;a href=&quot;https://review.whamcloud.com/35112/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/35112/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11952&quot; title=&quot;open+create resend can recreate a file after unlink&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11952&quot;&gt;&lt;del&gt;LU-11952&lt;/del&gt;&lt;/a&gt; mdt: fix reconstruct open&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: cf6ce3329f92f146206be8b63846d2c6e45c92d6&lt;/p&gt;</comment>
                            <comment id="320750" author="pjones" created="Mon, 13 Dec 2021 15:11:51 +0000"  >&lt;p&gt;Landed for 2.15&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="53448">LU-11444</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="54439">LU-11836</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|i00be7:</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>