<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:52:55 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-5603] Enable inline_data feature for Lustre</title>
                <link>https://jira.whamcloud.com/browse/LU-5603</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Now, we found ldiskfs(Ext4) directory creation is much slower than file creation.&lt;/p&gt;

&lt;p&gt;Under RHEL7 with ldiskfs, we got following results.&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;./mdtest -d /mnt/test/ -n 100000 -i 3&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Directory creation: 52299.122  ops/second&lt;br/&gt;
File creation: 106569 ops/second&lt;/p&gt;

&lt;p&gt;As we can see, directory creation performance is much slower than file creation, after doing some profiling, we found cost differences come from following calls:&lt;/p&gt;
&lt;div class=&apos;table-wrap&apos;&gt;
&lt;table class=&apos;confluenceTable&apos;&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-&amp;gt;ext4_mkdir()&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-&amp;gt;ext4_init_new_dir()&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-&amp;gt;ext4_append()&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-&amp;gt;ext4_bread()&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-&amp;gt;ext4_getblk()&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td class=&apos;confluenceTd&apos;&gt;-&amp;gt;ext4_map_blocks()&lt;br/&gt;
So here an extra block allocation for &apos;.&apos; and &apos;..&apos; items will cost extra time, and we enable inline_data which will reduce block allocation for such case, things got better:&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;
&lt;/div&gt;


&lt;p&gt;Directory creation: 111276.454 ops/second&lt;br/&gt;
File creation:  114920.338 ops/second&lt;/p&gt;

&lt;p&gt;As we can see, with inline_data enabled, directory creation performance is same as file creation.&lt;/p&gt;

&lt;p&gt;We also found inline_data feature not only help directory creation but also help&lt;br/&gt;
directory reading, consider following case:&lt;/p&gt;

&lt;ol&gt;
	&lt;li&gt;creating 100W directories under test directory and then run &apos;time ls -R ./test&apos;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;time cost reduce from 2m25s to 30s, huge differences! this is because inline_data will reduce an extra block allocation which also speed read performance as we don&apos;t have to do an extra block IO.&lt;/p&gt;

&lt;p&gt;In generally, Inline_data could improve performance and reduce space allocation which is also good. &lt;/p&gt;

&lt;p&gt;As now, inline_data is include in RHEL7 and there seems some conflicts with Lustre dirdata feature, but inline_data deserve us an eye, adding it to lustre will  give us some improvement thought we still confirm it under lustre.&lt;/p&gt;</description>
                <environment></environment>
        <key id="26471">LU-5603</key>
            <summary>Enable inline_data feature for Lustre</summary>
                <type id="2" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11311&amp;avatarType=issuetype">New Feature</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="dongyang">Dongyang Li</assignee>
                                    <reporter username="wangshilong">Wang Shilong</reporter>
                        <labels>
                            <label>ldiskfs</label>
                            <label>patch</label>
                    </labels>
                <created>Wed, 10 Sep 2014 02:57:37 +0000</created>
                <updated>Tue, 19 Dec 2023 07:02:56 +0000</updated>
                                                                                <due></due>
                            <votes>0</votes>
                                    <watches>11</watches>
                                                                            <comments>
                            <comment id="93681" author="pjones" created="Wed, 10 Sep 2014 13:12:18 +0000"  >&lt;p&gt;Hi there&lt;/p&gt;

&lt;p&gt;Is this an issue that you are planning to work on yourself or are you reporting it in the hope that somebody else will implement your suggestion?&lt;/p&gt;

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

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="93691" author="ihara" created="Wed, 10 Sep 2014 14:21:28 +0000"  >&lt;p&gt;Peter,&lt;br/&gt;
We would like to work on this.  There is a metadata performance  (directory creation and removal) limit. In order to confirm, we did some fundamental testing and confirmed &quot;inline_data&quot; siginicant improves the performance of directory metadata operations with ext4. And, it (or simiar way) is one of good candidates to break through today&apos;s lustre direcotry operation&apos;s performance.&lt;br/&gt;
Howerver, still some discussions are required to move forward since there is no compatibility of &quot;inline_data&quot; and &quot;dirdata&quot;.&lt;br/&gt;
First of all, we would like to test on Lustre with &quot;inline_data&quot; or keeping &quot;dirdata&quot; + similar way of &quot;inline_data&quot; is doing, then make sure this idea could work with Lustre as well. &lt;/p&gt;</comment>
                            <comment id="254720" author="adilger" created="Mon, 16 Sep 2019 11:15:01 +0000"  >&lt;p&gt;This feature will unfortunaately &lt;b&gt;not&lt;/b&gt; help with the IO-500 &lt;tt&gt;mdtest-hard-write&lt;/tt&gt; and &lt;tt&gt;mdtest-hard-read&lt;/tt&gt;, since the data cannot quite fit within the MDT inode even if it was formatted with a 4KB inode size.  The &lt;tt&gt;mdtest-hard-write&lt;/tt&gt; parameters create 3901-byte files, along with 160 bytes of the core inode and about 256 bytes of other xattrs are too large to fit even into a 4096-byte inode, if that were in use (which it is not).&lt;/p&gt;

&lt;p&gt;However, for the default 1024-byte MDT inode size, this would still improve performance for files below approximately 600 bytes in size, or directories with fewer than about 15 average-length (32-byte) filenames.  There are definitely some workloads (e.g. OpenFoam, at least in some uses) that may benefit significantly from faster small/empty directory creation speed, and some workloads have a lot of small files.&lt;/p&gt;</comment>
                            <comment id="302759" author="adilger" created="Thu, 27 May 2021 06:40:29 +0000"  >&lt;p&gt;The &lt;tt&gt;inline_data&lt;/tt&gt; feature will also help in the case of agent directory inodes created for remote/striped directories.  Instead of allocating a separate directory block to hold only &quot;&lt;tt&gt;.&lt;/tt&gt;&quot; and &quot;&lt;tt&gt;..&lt;/tt&gt;&quot;, it would be possible to store the &quot;&lt;tt&gt;..&lt;/tt&gt;&quot; entry + parent FID into the directory inode itself.  There is no need to store a &quot;&lt;tt&gt;.&lt;/tt&gt;&quot; entry, since this is stored in the inode itself and can be generated from inode-&amp;gt;i_ino and the self FID stored in &lt;tt&gt;trusted.lma&lt;/tt&gt;.&lt;/p&gt;</comment>
                            <comment id="394464" author="sthiell" created="Tue, 28 Nov 2023 03:14:11 +0000"  >&lt;p&gt;As far as I know, the &lt;tt&gt;dirdata&lt;/tt&gt; feature is still not available in ext4 and is currently maintained as an out-of-tree feature for Lustre via an ldiskfs patch named (&lt;tt&gt;ext4-data-in-dirent.patch&lt;/tt&gt;). This is leading to possible incompatibilities when trying to enable newer ext4 features like &lt;tt&gt;inline_data&lt;/tt&gt; with Lustre. I just tried to enable it on EL 9.2 using &lt;tt&gt;mkfs.lustre -O inline_data ...&lt;/tt&gt; and the underlying &lt;tt&gt;mke2fs&lt;/tt&gt; command returns &quot;The dirdata feature can not enabled with inline data feature.&quot;. If I try to format with &lt;tt&gt;-O ^dirdata,inline_data&lt;/tt&gt;, the MDT complaints about missing &lt;tt&gt;dirdata&lt;/tt&gt; and then crashes (kernel BUG) in ldiskfs (this is with master from a couple weeks).&lt;/p&gt;

&lt;p&gt;Is there any solution in sight so Lustre could benefit from &lt;tt&gt;inline_data?&lt;/tt&gt; It seems it would give some performance benefits (maybe not for the IO-500 benchmarks but more likely for real life use cases...) and could also potentially greatly reduce the blocks consumed by small directories. Our own interest for&#160;&lt;tt&gt;inline_data&lt;/tt&gt; is not performance-related (although it&apos;s always welcome)... but rather in storing a very large amount of very small directories in Lustre so that it can be used more efficiently as a MinIO disk.&lt;/p&gt;</comment>
                            <comment id="394474" author="adilger" created="Tue, 28 Nov 2023 06:01:31 +0000"  >&lt;p&gt;Stephane, yes the incompatibility with upstream is known to me. That is why we haven&apos;t enabled this feature yet. It will need some ldiskfs development effort to allow these features to work together. &lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="53868">LU-11589</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="46605">LU-9627</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="73446">LU-16355</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="76667">LU-16921</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                            <subtask id="53868">LU-11589</subtask>
                    </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_10490" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>End date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 10 Sep 2014 02:57:37 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                            <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|hzwvwn:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>15672</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                <customfield id="customfield_10493" key="com.atlassian.jira.plugin.system.customfieldtypes:datepicker">
                        <customfieldname>Start date</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>Wed, 10 Sep 2014 02:57:37 +0000</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    </customfields>
    </item>
</channel>
</rss>