<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:06:14 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-7128] Performance improvements for out_read()</title>
                <link>https://jira.whamcloud.com/browse/LU-7128</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;To read update records, it needs to do bulk buffer read between MDTs (see out_read()), and because we use osd_write to write update records into the disk see osd_write, which will write directly to buffer, so we have to use osd_read to read buffer back. But that has performance issue, &lt;/p&gt;

&lt;p&gt;From Andreas   &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;This is submitting the reads to disk as a series of separate reads (i.e. a seek between each one) which is inefficient.
This should use the same method ofd_preprw_read() and ofd_commitrw_read() does for reading - dt_bufs_get(), dt_read_prep(), dt_bufs_put(). That submits all the pages to be read at once and will avoid any seek if they are contiguous on disk.
Unfortunately, the code layering makes it difficult to reuse or share any code with tgt_brw_read() since tgt_brw_read() calls into ofd_* while this calls directly into dt_*. At a minimum, this should copy the checks in tgt_brw_read() to see if the client is evicted so that it doesn&apos;t block waiting for sends that could never finish, and have a comment referencing tgt_brw_read() so that we know the code should be similar.
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;But if we change the read to OST read style( use osd_read_prep etc), that might cause some cache conference issue.&lt;/p&gt;</description>
                <environment></environment>
        <key id="32024">LU-7128</key>
            <summary>Performance improvements for out_read()</summary>
                <type id="2" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11311&amp;avatarType=issuetype">New Feature</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</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="wc-triage">WC Triage</assignee>
                                    <reporter username="di.wang">Di Wang</reporter>
                        <labels>
                    </labels>
                <created>Thu, 10 Sep 2015 05:52:18 +0000</created>
                <updated>Thu, 10 Sep 2015 17:45:09 +0000</updated>
                                            <version>Lustre 2.8.0</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>6</watches>
                                                                            <comments>
                            <comment id="126892" author="bzzz" created="Thu, 10 Sep 2015 10:40:37 +0000"  >&lt;p&gt;both osd_read() and all forms of write operate on the same cache, so I don&apos;t expect any cache coherency issues. races are possible if no external locking is used, but this is normal.&lt;br/&gt;
OSP can be doing read-ahead to improve performance. also, I think the right approach to this (and other issues related to llog) is to reconsider llog format.&lt;/p&gt;
</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="30730">LU-6741</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|hzxn2f:</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>