<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:33:34 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-3399] MDT don&apos;t update client last commited correctly so produce OOM on client</title>
                <link>https://jira.whamcloud.com/browse/LU-3399</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Cray customer hit a OOM with using a lustre and Robin-Hood application.&lt;br/&gt;
Per internal investigation - application issued a ls -lRa /mnt/lustre for a lustre mount with noatime option. In that case all open/close requests lives in replay cache and wait until it&apos;s committed (in cray case ~100k .. 200k requests lives in slab cache). These requests wait a commit from MDT side but none have as client have a open/close/getattr request don&apos;t generate a any real transaction. &lt;br/&gt;
it&apos;s easy replicated with - prepare a fs with large number a directories, stop lustre, run&lt;br/&gt;
1) MOUNTOPT=&quot;-o user_xattr,flock,noatime&quot; PTLDEBUG=-1 SUBSYSTEM=-1 DEBUG_SIZE=800 NOFORMAT=yes sh llmount.sh &lt;br/&gt;
2) Starting client: rhel6-64.shadowland: -o user_xattr,flock,noatime rhel6-64.shadowland@tcp:/lustre /mnt/lustre&lt;br/&gt;
Using TIMEOUT=20&lt;br/&gt;
disable quota as required&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rhel6-64 tests&amp;#93;&lt;/span&gt;# lctl dk log1&lt;br/&gt;
Debug log: 148739 lines, 148739 kept, 0 dropped, 0 bad.&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rhel6-64 tests&amp;#93;&lt;/span&gt;# ls -lRa /mnt/lustre &amp;gt; /dev/null&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rhel6-64 tests&amp;#93;&lt;/span&gt;# mount -t lustre -o user_xattr,flock,noatime rhel6-64.shadowland@tcp:/lustre /mnt/lustre2&lt;br/&gt;
&lt;span class=&quot;error&quot;&gt;&amp;#91;root@rhel6-64 tests&amp;#93;&lt;/span&gt;# grep rpc_cache /proc/slabinfo &lt;br/&gt;
rpc_cache           2466   2695   1168    7    2 : tunables   24   12    8 : slabdata    385    385      0 : globalstat   11338   2695   389    3 				   0   10    0    0    0 : cpustat  29477   1686  27471   1238&lt;/p&gt;

&lt;p&gt;(patch to move ptlrpc request in slab -  wait a WC/Intel review).&lt;/p&gt;

&lt;p&gt;so after simple ls -lRa we have 2500 active requests...&lt;br/&gt;
bug hit.&lt;/p&gt;

&lt;p&gt;to flush these requests need touch $some_file_on_lustre.&lt;br/&gt;
but any touch in different mount point don&apos;t flush a request cache.&lt;/p&gt;

&lt;p&gt;per additional investigation - I found MDT send a zero as last committed to the affected client, where client2 have a correct last committed updates. &lt;/p&gt;

&lt;p&gt;As i see, target_to_commited_req send a just per export committed info to the client, instead of use a global data. In that case buggy client don&apos;t able to commit a requests in base of different client activity. &lt;/p&gt;

&lt;p&gt;Can someone explain why it&apos;s used instead of global obd_last_commited?&lt;br/&gt;
simple patch have reduce problem for my.&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;diff --git a/lustre/ldlm/ldlm_lib.c b/lustre/ldlm/ldlm_lib.c
index 31ffbc9..99f2f26 100644
--- a/lustre/ldlm/ldlm_lib.c
+++ b/lustre/ldlm/ldlm_lib.c
@@ -2529,7 +2529,8 @@ &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; target_committed_to_req(struct ptlrpc_request *req)
 
         &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (likely(!exp-&amp;gt;exp_obd-&amp;gt;obd_no_transno &amp;amp;&amp;amp; req-&amp;gt;rq_repmsg != NULL)) {
                 lustre_msg_set_last_committed(req-&amp;gt;rq_repmsg,
-                                              exp-&amp;gt;exp_last_committed);
+                                               exp-&amp;gt;exp_obd-&amp;gt;obd_last_committed);
+&lt;span class=&quot;code-comment&quot;&gt;//                                              exp-&amp;gt;exp_last_committed);
&lt;/span&gt;         } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                 DEBUG_REQ(D_IOCTL, req, &lt;span class=&quot;code-quote&quot;&gt;&quot;not sending last_committed update (%d/&quot;&lt;/span&gt;
                           &lt;span class=&quot;code-quote&quot;&gt;&quot;%d)&quot;&lt;/span&gt;, exp-&amp;gt;exp_obd-&amp;gt;obd_no_transno,
@@ -2537,8 +2538,8 @@ &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; target_committed_to_req(struct ptlrpc_request *req)
                ret = 0;
        }
 
-        CDEBUG(D_INFO, &lt;span class=&quot;code-quote&quot;&gt;&quot;last_committed &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;, transno &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;, xid &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;\n&quot;&lt;/span&gt;,
-               exp-&amp;gt;exp_last_committed, req-&amp;gt;rq_transno, req-&amp;gt;rq_xid);
+        CDEBUG(D_INFO, &lt;span class=&quot;code-quote&quot;&gt;&quot;last_committed &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;/&quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;, transno &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;, xid &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot;\n&quot;&lt;/span&gt;,
+               exp-&amp;gt;exp_last_committed, exp-&amp;gt;exp_obd-&amp;gt;obd_last_committed, req-&amp;gt;rq_transno, req-&amp;gt;rq_xid);
        &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt; ret;
 }
 EXPORT_SYMBOL(target_committed_to_req);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;cache have reduced after next ping.&lt;/p&gt;</description>
                <environment>lustre mounted with noatime or relatime mount option.</environment>
        <key id="19158">LU-3399</key>
            <summary>MDT don&apos;t update client last commited correctly so produce OOM on client</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</priority>
                        <status id="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="bogl">Bob Glossman</assignee>
                                    <reporter username="shadow">Alexey Lyashkov</reporter>
                        <labels>
                            <label>patch</label>
                    </labels>
                <created>Sun, 26 May 2013 20:56:30 +0000</created>
                <updated>Tue, 2 Dec 2014 15:59:58 +0000</updated>
                                            <version>Lustre 2.0.0</version>
                    <version>Lustre 2.1.0</version>
                    <version>Lustre 2.2.0</version>
                    <version>Lustre 2.3.0</version>
                    <version>Lustre 2.4.0</version>
                    <version>Lustre 1.8.x (1.8.0 - 1.8.5)</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>8</watches>
                                                                            <comments>
                            <comment id="59342" author="bzzz" created="Mon, 27 May 2013 03:32:55 +0000"  >&lt;p&gt;I think this is a dup of &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2613&quot; title=&quot;opening and closing file can generate &amp;#39;unreclaimable slab&amp;#39; space&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2613&quot;&gt;&lt;del&gt;LU-2613&lt;/del&gt;&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="59355" author="aboyko" created="Mon, 27 May 2013 06:19:11 +0000"  >&lt;p&gt;patch &lt;a href=&quot;http://review.whamcloud.com/#change,6456&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#change,6456&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="59365" author="shadow" created="Mon, 27 May 2013 10:26:08 +0000"  >&lt;p&gt;well, &lt;br/&gt;
bug introduced before 1.8.0 in b1_8_gate branch, but i don&apos;t find a corresponding commit (cvs ver 1.96.6.38.2.3).&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;1.90         (nathan   10-Feb-07): void target_committed_to_req(struct ptlrpc_request *req)
1.90         (nathan   10-Feb-07): {
1.96.6.38.2.3 (johann   18-Dec-08):         struct obd_export *exp = req-&amp;gt;rq_export;
1.96.6.38.2.3 (johann   18-Dec-08):         &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (!exp-&amp;gt;exp_obd-&amp;gt;obd_no_transno &amp;amp;&amp;amp; req-&amp;gt;rq_repmsg != NULL) {
1.90         (nathan   10-Feb-07):                 lustre_msg_set_last_committed(req-&amp;gt;rq_repmsg,
1.96.6.38.2.3 (johann   18-Dec-08):                                               exp-&amp;gt;exp_last_committed);
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;before it change we always use a obd_last_commited to send to client.&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;void target_committed_to_req(struct ptlrpc_request *req)
{
 &#160; &#160; &#160; &#160;struct obd_device *obd = req-&amp;gt;rq_export-&amp;gt;exp_obd;

 &#160; &#160; &#160; &#160;&lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (!obd-&amp;gt;obd_no_transno &amp;amp;&amp;amp; req-&amp;gt;rq_repmsg != NULL)
 &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;req-&amp;gt;rq_repmsg-&amp;gt;last_committed = obd-&amp;gt;obd_last_committed

...
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;that bug may produce OOM on client, as may block a release a BRW rpc from replay queue also.&lt;/p&gt;</comment>
                            <comment id="59367" author="shadow" created="Mon, 27 May 2013 11:25:21 +0000"  >&lt;p&gt;finally identified as bug in VBR patch.&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://projectlava.xyratex.com/show_bug.cgi?id=16353&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://projectlava.xyratex.com/show_bug.cgi?id=16353&lt;/a&gt;&lt;br/&gt;
&lt;a href=&quot;https://projectlava.xyratex.com/attachment.cgi?id=21306&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://projectlava.xyratex.com/attachment.cgi?id=21306&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="59368" author="tappro" created="Mon, 27 May 2013 12:18:04 +0000"  >&lt;p&gt;That was done to reduce contention on last_rcvd header update, per-export last_committed track also is needed for VBR and delayed recovery specifically, each export may recover without affecting whole server data but using only own client data.&lt;/p&gt;

&lt;p&gt;In our case the simplest way to fix that would be using max(exp_last_committed, obd_last_committed) in target_committed_to_req() function. This will give us the highest value. Strictly speaking this breaks &apos;delayed recovery&apos; feature but it was never finished to be real product feature so we may don&apos;t care about it.&lt;/p&gt;

&lt;p&gt;Meanwhile this is also not full solution, consider the case when many clients do only opens and there is no disk update on server at all. I don&apos;t even think it is right to solve that on server. I wrote some thoughts in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2613&quot; title=&quot;opening and closing file can generate &amp;#39;unreclaimable slab&amp;#39; space&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2613&quot;&gt;&lt;del&gt;LU-2613&lt;/del&gt;&lt;/a&gt; what can be done, we need to solve that on client, IMHO, but this is long way and it requires more effort. &lt;/p&gt;
</comment>
                            <comment id="59372" author="shadow" created="Mon, 27 May 2013 13:03:53 +0000"  >&lt;p&gt;I don&apos;t ask about &quot;why per-export last_commited info is need&quot;, i understand it - question about client side updates.&lt;br/&gt;
per obd_commited_cb() per export committed info always less or same for a cluster wide info, but it&apos;s in run time and generic recovery.&lt;/p&gt;

&lt;p&gt;as about recovery - we need correctly track a higher commits number in last_rcvd anyway, if i correctly understand - you talk about VBR with clients connected after recovery window closed? but it&apos;s should be replayed with using a lock/inode version as base and don&apos;t rely to transaction info in recovery.&lt;/p&gt;

&lt;p&gt;I agree about complex solution, but it fix created just to fix for 2.4 and continue to create a final solution in next release. May be we need both patches from &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2613&quot; title=&quot;opening and closing file can generate &amp;#39;unreclaimable slab&amp;#39; space&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2613&quot;&gt;&lt;del&gt;LU-2613&lt;/del&gt;&lt;/a&gt; and it, but i think 2613 generate additional disk load &lt;/p&gt;</comment>
                            <comment id="59373" author="bzzz" created="Mon, 27 May 2013 13:08:12 +0000"  >&lt;p&gt;&quot;per export committed info always less or same for a cluster wide info&quot; - this is not true as we do NOT want to maintain global last_committed to improve SMP scalability.&lt;/p&gt;

&lt;p&gt;the original point was that &quot;per-MDT&quot; last committed is not enough to fix the issue if another clients aren&apos;t generating new transno.&lt;br/&gt;
so another solution (already implemented by Niu) is needed.&lt;/p&gt;</comment>
                            <comment id="59377" author="shadow" created="Mon, 27 May 2013 13:28:47 +0000"  >&lt;p&gt;&amp;gt; &quot;per export committed info always less or same for a cluster wide info&quot; - this is not true as we do NOT want to maintain global last_committed to improve SMP scalability.&lt;/p&gt;

&lt;p&gt;Single thread have updates - many threads have reads - where you find a scalability problem in that case?&lt;br/&gt;
that is totally lock less work.&lt;/p&gt;

&lt;p&gt;&amp;gt; the original point was that &quot;per-MDT&quot; last committed is not enough to fix the issue if another clients aren&apos;t generating new transno. so another solution (already implemented by Niu) is needed.&lt;/p&gt;

&lt;p&gt;first of all, it&apos;s add&apos;s additional disk load - so it&apos;s too bad by definition - because disk is most slow part and mostly contended. I may be agree with fake commit callback assigned without disk updates but just update a per export value. &lt;/p&gt;
</comment>
                            <comment id="59380" author="tappro" created="Mon, 27 May 2013 13:37:30 +0000"  >&lt;p&gt;obd_last_committed is not updated per each transaction, it is used just as &apos;reserve&apos; storage for cases when we cannot write transno at client data, e.g. client umount. That way we have no contention on last_rcvd header, each client updates only own slot in most cases. Therefore per-client last_committed usually bigger then obd one. That is why you cannot use only obd_last_committed, it is NOT the latest value.&lt;/p&gt;

&lt;p&gt; The patch in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2613&quot; title=&quot;opening and closing file can generate &amp;#39;unreclaimable slab&amp;#39; space&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2613&quot;&gt;&lt;del&gt;LU-2613&lt;/del&gt;&lt;/a&gt; might be acceptable solution for now, maybe we can even decrease number of transaction to 100. I don&apos;t think that extra disk load is a problem, it happens rarely.&lt;/p&gt;
</comment>
                            <comment id="59393" author="shadow" created="Mon, 27 May 2013 19:29:28 +0000"  >&lt;p&gt;&amp;gt; obd_last_committed is not updated per each transaction..&lt;br/&gt;
&amp;gt; That is why you cannot use only obd_last_committed, it is NOT the latest value.&lt;br/&gt;
really?&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;static&lt;/span&gt; inline void obd_transno_commit_cb(struct obd_device *obd, __u64 transno,
                                         struct obd_export *exp, &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; error)
{
        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (error) {
                CERROR(&lt;span class=&quot;code-quote&quot;&gt;&quot;%s: transno &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot; commit error: %d\n&quot;&lt;/span&gt;,
                       obd-&amp;gt;obd_name, transno, error);
                &lt;span class=&quot;code-keyword&quot;&gt;return&lt;/span&gt;;
        }
        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (exp &amp;amp;&amp;amp; transno &amp;gt; exp-&amp;gt;exp_last_committed) {
                CDEBUG(D_HA, &lt;span class=&quot;code-quote&quot;&gt;&quot;%s: transno &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot; committed\n&quot;&lt;/span&gt;,
                       obd-&amp;gt;obd_name, transno);
                exp-&amp;gt;exp_last_committed = transno;
                ptlrpc_commit_replies(exp);
        } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                CDEBUG(D_INFO, &lt;span class=&quot;code-quote&quot;&gt;&quot;%s: transno &quot;&lt;/span&gt;LPU64&lt;span class=&quot;code-quote&quot;&gt;&quot; committed\n&quot;&lt;/span&gt;,
                       obd-&amp;gt;obd_name, transno);
        }
        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (transno &amp;gt; obd-&amp;gt;obd_last_committed)
                obd-&amp;gt;obd_last_committed = transno;
}

&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;or for master&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;void tgt_cb_last_committed(struct lu_env *env, struct thandle *th,
                           struct dt_txn_commit_cb *cb, &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; err)
{
        struct tgt_last_committed_callback *ccb;

        ccb = container_of0(cb, struct tgt_last_committed_callback, llcc_cb);

        LASSERT(ccb-&amp;gt;llcc_tgt != NULL);
        LASSERT(ccb-&amp;gt;llcc_exp-&amp;gt;exp_obd == ccb-&amp;gt;llcc_tgt-&amp;gt;lut_obd);

        spin_lock(&amp;amp;ccb-&amp;gt;llcc_tgt-&amp;gt;lut_translock);
        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (ccb-&amp;gt;llcc_transno &amp;gt; ccb-&amp;gt;llcc_tgt-&amp;gt;lut_obd-&amp;gt;obd_last_committed)
                ccb-&amp;gt;llcc_tgt-&amp;gt;lut_obd-&amp;gt;obd_last_committed = ccb-&amp;gt;llcc_transno;
                
        LASSERT(ccb-&amp;gt;llcc_exp);
        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (ccb-&amp;gt;llcc_transno &amp;gt; ccb-&amp;gt;llcc_exp-&amp;gt;exp_last_committed) {
                ccb-&amp;gt;llcc_exp-&amp;gt;exp_last_committed = ccb-&amp;gt;llcc_transno;
                spin_unlock(&amp;amp;ccb-&amp;gt;llcc_tgt-&amp;gt;lut_translock);
                ptlrpc_commit_replies(ccb-&amp;gt;llcc_exp);
        } &lt;span class=&quot;code-keyword&quot;&gt;else&lt;/span&gt; {
                spin_unlock(&amp;amp;ccb-&amp;gt;llcc_tgt-&amp;gt;lut_translock);
        }
        class_export_cb_put(ccb-&amp;gt;llcc_exp);
        &lt;span class=&quot;code-keyword&quot;&gt;if&lt;/span&gt; (ccb-&amp;gt;llcc_transno)
                CDEBUG(D_HA, &lt;span class=&quot;code-quote&quot;&gt;&quot;%s: transno &quot;&lt;/span&gt;LPD64&lt;span class=&quot;code-quote&quot;&gt;&quot; is committed\n&quot;&lt;/span&gt;,
                       ccb-&amp;gt;llcc_tgt-&amp;gt;lut_obd-&amp;gt;obd_name, ccb-&amp;gt;llcc_transno);
        OBD_FREE_PTR(ccb);
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;so it&apos;s updated in same time as exp_last_commited does. I don&apos;t see why it&apos;s don&apos;t have lasts data.&lt;/p&gt;

&lt;p&gt;&amp;gt; That way we have no contention on last_rcvd header, each client updates only own slot in most cases.&lt;br/&gt;
again. I don&apos;t talk about on disk updates - i talk about runtime.&lt;/p&gt;


&lt;p&gt;&amp;gt; I don&apos;t think that extra disk load is a problem, it happens rarely.&lt;br/&gt;
You really think &apos;ls&apos; tool is rare used? or any readdir() users.&lt;/p&gt;</comment>
                            <comment id="59403" author="tappro" created="Tue, 28 May 2013 07:10:12 +0000"  >&lt;p&gt;yes, you are right about memory value, I had impression we are talking about disk.&lt;/p&gt;

&lt;p&gt;&apos;Happens rarely&apos; was about extra disk load happens with Niu patch, it happens once per 1000 opens and if there are no more other updates, this is rare case.&lt;/p&gt;

&lt;p&gt;Speaking about using obd_last_committed, it breaks VBR features because whole idea was about each client may recover independently from others, so each client maintain own state of committed transaction, it is not cluster-wide since VBR was introduced. Independent client recovery opens way to better server recovery mechanisms like delayed recovery and parallel recovery, that is why I don&apos;t want to break this now if there is another way, just because we will return to this problem again in future and will solve it again. I&apos;d prefer to solve it properly now. As I can see Niu patch in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-2613&quot; title=&quot;opening and closing file can generate &amp;#39;unreclaimable slab&amp;#39; space&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-2613&quot;&gt;&lt;del&gt;LU-2613&lt;/del&gt;&lt;/a&gt; can do the job keeping the using exp_last_committed usage in target_committed_to_req() but bumping it time to time to helps client with stuck open requests. Do you think that patch is not enough?&lt;/p&gt;</comment>
                            <comment id="59405" author="shadow" created="Tue, 28 May 2013 07:38:18 +0000"  >&lt;p&gt;Tappro,&lt;/p&gt;

&lt;p&gt;Niu patch eats space in journal, that is one more objection and we may don&apos;t have 1000 commits to trigger a Niu exp_last_commited updates. I will be happy if patch will add&apos;s a just commit callback to update a per export value and don&apos;t touch disk for each fake commit, may be we need additional API or just move some logic to MDD layer.&lt;/p&gt;

&lt;p&gt;as about using obd_last_committed, from my point view - it&apos;s not a differences between have a snapshot of committed ID via introducing a fake commits, and take same info from a global variable - anyway it&apos;s point to same data, but i think it&apos;s easy because client will be get a last committed updates early, and it&apos;s may affect a BRW requests also - as they may don&apos;t have any real transaction but need to be know about last committed to release own resources (it&apos;s my idea, but i really don&apos;t check in code - just reading long long time Adilger commit - why obd_last_committed used). &lt;/p&gt;</comment>
                            <comment id="59410" author="bzzz" created="Tue, 28 May 2013 09:09:30 +0000"  >&lt;p&gt;Niu&apos;s patch will &quot;eat&quot; one block every 5s per client at most. with 1GB journal, a transaction limit is 65536 blocks.&lt;/p&gt;</comment>
                            <comment id="59412" author="shadow" created="Tue, 28 May 2013 09:27:24 +0000"  >&lt;p&gt;with 10k clients - it&apos;s eats 10k blocks each 5s - so it&apos;s will eat 1/6 of journal size will used to store a fake commits.&lt;/p&gt;</comment>
                            <comment id="59415" author="bzzz" created="Tue, 28 May 2013 09:33:17 +0000"  >&lt;p&gt;(gdb) p sizeof(struct lsd_client_data)&lt;br/&gt;
$1 = 128&lt;/p&gt;

&lt;p&gt;so, it should be nearly 320000 clients very evenly distributed over last_rcvd to consume 10K blocks. which is very unlikely.&lt;br/&gt;
with just 10K clients all doing &quot;this&quot;, it&apos;s just 10000*128/4096=313 blocks. and this is essentially the only activity...&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                            <outwardlinks description="duplicates">
                                        <issuelink>
            <issuekey id="17161">LU-2613</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|hzvrvr:</customfieldvalue>

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