<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:58:19 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-6220] push ext4/ldiskfs patches upstream if possible</title>
                <link>https://jira.whamcloud.com/browse/LU-6220</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;There are a number of ldiskfs patches that we could potentially push upstream, possibly with some cleanups.  All patches should be run through checkpatch.pl first.&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;ext4-print-inum-in-htree-warning.patch: could be pushed upstream after moving string to the next line so it fits inside 80 columns&lt;/li&gt;
	&lt;li&gt;&lt;del&gt;ext4-disable-mb-cache.patch: I was involved in some discussion upstream about removing the mbcache (&lt;a href=&quot;http://lwn.net/Articles/564802/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://lwn.net/Articles/564802/&lt;/a&gt;), but that patch was never accepted upstream. We could try pushing this patch again, since it is fairly simple, and it wouldn&apos;t be very incompatible with the other mbcache speedup patch if that was ever landed.&lt;/del&gt;&lt;/li&gt;
	&lt;li&gt;ext4-inode-version.patch: It might be possible to submit a patch upstream that moves &lt;tt&gt;dir-&amp;gt;i_version++&lt;/tt&gt; into ext4_mark_iloc_dirty() like &lt;tt&gt;if (IS_I_VERSION(inode) || S_ISDIR(dir))&lt;/tt&gt;. Then, we can add a mount flag or patch that makes this check a no-op so we only need a very small patch. More importantly, it will reduce the size of ext4_inode_info because we don&apos;t need a separate i_fs_version and reduce the memory usage on the MDS.&lt;/li&gt;
	&lt;li&gt;ext4-journal-path-opt.patch: I think this can be pushed upstream without any significant changes&lt;/li&gt;
	&lt;li&gt;ext4-kill-dx-root.patch: could be submitted upstream as a cleanup with some style fixes&lt;/li&gt;
	&lt;li&gt;ext4-max-dir-size.patch: we should print out a deprecation warning in newer kernels to mount with &quot;-o max_dir_size_kb&quot; instead, and then we can eventually remove it? The mount option has existed since kernel 3.6, maybe it would be better to backport support for the mount option to RHEL6 instead of maintaining this patch forever?&lt;/li&gt;
	&lt;li&gt;ext4-large-eas.patch: this is described in &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-908&quot; title=&quot;multi-block xattr support&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-908&quot;&gt;&lt;del&gt;LU-908&lt;/del&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
        <key id="28587">LU-6220</key>
            <summary>push ext4/ldiskfs patches upstream if possible</summary>
                <type id="4" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11310&amp;avatarType=issuetype">Improvement</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="ys">Yang Sheng</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                    </labels>
                <created>Fri, 6 Feb 2015 11:41:05 +0000</created>
                <updated>Sat, 13 Jan 2024 17:27:57 +0000</updated>
                                            <version>Lustre 2.8.0</version>
                                    <fixVersion>Upstream</fixVersion>
                                        <due></due>
                            <votes>1</votes>
                                    <watches>13</watches>
                                                                            <comments>
                            <comment id="122116" author="ys" created="Fri, 24 Jul 2015 13:55:00 +0000"  >&lt;p&gt;As latest 4.2 kernel status:&lt;br/&gt;
 ext4-print-inum-in-htree-warning.patch: Already merged by commit b03a2f7eb21cc06b541142684abf7eed6aaccf3e&lt;br/&gt;
 ext4-journal-path-opt.patch: Already merged by commit ad4eec613536dc7e5ea0c6e59849e6edca634d8b&lt;/p&gt;

&lt;p&gt;So just 3 patches need to push upstream.&lt;br/&gt;
 ext4-disable-mb-cache.patch&lt;br/&gt;
 ext4-kill-dx-root.patch&lt;br/&gt;
 ext4-large-dir.patch&lt;br/&gt;
But they are conflict heavily against latest kernel tree. I&apos;ll work out a draft and attached here for review.&lt;/p&gt;

</comment>
                            <comment id="122176" author="simmonsja" created="Fri, 24 Jul 2015 20:31:59 +0000"  >&lt;p&gt;Only 3 more. A lot more patch exist that need to merged upstream to make ldiskfs patchless.&lt;/p&gt;</comment>
                            <comment id="124019" author="ys" created="Thu, 13 Aug 2015 04:50:45 +0000"  >&lt;p&gt;From &lt;a href=&quot;http://review.whamcloud.com/#/c/15961/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/15961/&lt;/a&gt; for record&lt;/p&gt;

&lt;p&gt;Andreas Dilger                                          4:09 AM&lt;/p&gt;

&lt;p&gt;Patch Set 5: Code-Review+2&lt;/p&gt;

&lt;p&gt;This is much better than before, but not 100% safe if there is another flag used by ext4.&lt;/p&gt;

&lt;p&gt;It might be useful to try to push a patch upstream that puts BH_BITMAP_DIRTY into an enum with a &quot;last&quot; value to allow us to ensure that BH_DXLock does not conflict. The reason for the upstream patch could be to verify that BH_BITMAP_DIRTY itself does not overflow the b_state field.&lt;/p&gt;</comment>
                            <comment id="225708" author="adilger" created="Wed, 11 Apr 2018 06:48:08 +0000"  >&lt;p&gt;The &lt;tt&gt;ext4-kill-dx-root&lt;/tt&gt;, &lt;tt&gt;ext4-large-dir&lt;/tt&gt;, and &lt;tt&gt;ext4-disable-mbcache&lt;/tt&gt; patches were landed in the upstream 4.12 kernel.&lt;/p&gt;

&lt;p&gt;The &lt;tt&gt;ext4-large-eas&lt;/tt&gt; patch was landed in the upstream 4.13 kernel.&lt;/p&gt;

&lt;p&gt;The &lt;tt&gt;ext4-data-in-dirent&lt;/tt&gt; patch is scheduled to land for the upstream 4.17 kernel.&lt;/p&gt;

&lt;p&gt;In the 4.15 kernel, upstream commit &lt;tt&gt;&lt;a href=&quot;https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae5e165d855&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;ae5e165d855&lt;/a&gt;&lt;/tt&gt; and commit &lt;tt&gt;&lt;a href=&quot;https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee73f9a52a34&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;ee73f9a52a34&lt;/a&gt;&lt;/tt&gt; changed how &lt;tt&gt;i_version&lt;/tt&gt; is handled by the VFS and the filesystems.  We may be able to leverage this change to remove the &lt;tt&gt;ext4-inode-version&lt;/tt&gt; patch.  In particular, if we do not set the &lt;tt&gt;SB_I_VERSION&lt;/tt&gt; flag in the superblock, the VFS will no longer modify the &lt;tt&gt;i_version&lt;/tt&gt; field in the inode, so we may be able to avoid storing the Lustre version in &lt;tt&gt;struct ext4_inode.i_fs_version&lt;/tt&gt;, and can use &lt;tt&gt;struct inode.i_version&lt;/tt&gt; for this (save 8 bytes per ldiskfs inode and an ldiskfs patch).&lt;/p&gt;

&lt;p&gt;The &lt;tt&gt;ext4-nocmtime&lt;/tt&gt; patch took a bit of a step backward in kernel 4.9, since the &lt;tt&gt;ext4_current_time()&lt;/tt&gt; wrapper that we were using so conveniently was removed and replaced with dozen(s) of direct calls to &lt;tt&gt;current_time()&lt;/tt&gt; from the VFS.&lt;/p&gt;

&lt;p&gt;The &lt;tt&gt;ext4-mmp-brelse&lt;/tt&gt; patch equivalent landed upstream in kernel 4.5.&lt;/p&gt;</comment>
                            <comment id="225981" author="simmonsja" created="Fri, 13 Apr 2018 13:37:56 +0000"  >&lt;p&gt;What is left? Its sounds like we are almost complete for this work.&lt;/p&gt;</comment>
                            <comment id="226437" author="adilger" created="Thu, 19 Apr 2018 23:38:17 +0000"  >&lt;p&gt;The current &lt;tt&gt;ldiskfs-4.4-sles12sp3&lt;/tt&gt; patch series looks like the following (patches marked &apos;*&apos; are/will be merged soon):&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;sles12sp2/ext4-inode-version.patch
sles12sp2/ext4-lookup-dotdot.patch
sles12sp2/ext4-print-inum-in-htree-warning.patch
sles12sp2/ext4-prealloc.patch
sles12sp2/ext4-osd-iop-common.patch
sles12sp2/ext4-misc.patch
sles12sp3/ext4-mballoc-extra-checks.patch
sles12sp2/ext4-hash-indexed-dir-dotdot-update.patch
sles12sp2/ext4-kill-dx-root.patch *
rhel7/ext4-mballoc-pa-free-mismatch.patch
sles12sp2/ext4-data-in-dirent.patch *
sles12sp2/ext4-large-eas.patch *
sles12sp2/ext4-disable-mb-cache.patch *
rhel7/ext4-nocmtime.patch
sles12sp2/ext4-large-dir.patch *
sles12sp2/ext4-pdirop.patch
sles12sp2/ext4-max-dir-size.patch
rhel7/ext4-remove-truncate-warning.patch
sles12sp3/ext4-corrupted-inode-block-bitmaps-handling-patches.patch * (just under discussion)
sles12sp2/ext4-give-warning-with-dir-htree-growing.patch
sles12sp2/ext4-mmp-brelse.patch *
rhel7/ext4-jcb-optimization.patch
sles12sp2/ext4-attach-jinode-in-writepages.patch
sles12sp2/ext4-dont-check-before-replay.patch
rhel7.2/ext4-dont-check-in-ro.patch
sles12sp2/ext4-fix-xattr-shifting-when-expanding-inodes.patch *
rhel7/ext4-use-GFP_NOFS-in-ext4_inode_attach_jinode.patch
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;There may be slightly different patches in the RHEL7 kernel series, but it is against a significantly older kernel so I didn&apos;t want to use that as a starting point.  This shows there are definitely still a lot of patches to be merged and/or worked around in some other way.  At least several of the major on-disk features have been landed, and most of these are only related to in-core changes (API, functionality), so the risk of incompatible on-disk formats is significantly reduced.  I&apos;m hoping that &lt;tt&gt;e2fsprogs-1.45&lt;/tt&gt; &lt;em&gt;might&lt;/em&gt; even be able to run &lt;tt&gt;e2fsck&lt;/tt&gt; against an OST or MDT, though I don&apos;t think it would be advised without more testing.&lt;/p&gt;</comment>
                            <comment id="268736" author="ys" created="Tue, 28 Apr 2020 07:14:46 +0000"  >&lt;p&gt;Move from &lt;a href=&quot;https://review.whamcloud.com/38372&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/38372&lt;/a&gt; as record&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Now you have moved htree locking in a separate patch.  I &lt;b&gt;don&apos;t&lt;/b&gt; think it will be possible to get this merged until there is parallel VFS directory locking in the kernel, but at least it cleans up our own patches.&lt;/p&gt;

&lt;p&gt;I think it may be possible to get the ext4-kill-dx-root.patch merged upstream as a code cleanup, which would avoid the need to carry that patch in the Lustre tree forever.&lt;/p&gt;

&lt;p&gt;It would be possible to get ext4-data-in-dirent.patch upstream, if we added an ioctl interface for being able to get/set the FID for testing, and similar patches for debugfs to get/set the FID for testing.&lt;/p&gt;&lt;/blockquote&gt;</comment>
                            <comment id="272592" author="adilger" created="Thu, 11 Jun 2020 09:43:42 +0000"  >&lt;p&gt;Patch &lt;a href=&quot;https://review.whamcloud.com/38372&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/38372&lt;/a&gt; &quot;&lt;tt&gt;&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-13054&quot; title=&quot;MDS kernel BUG at ldiskfs/htree_lock.c:429!&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-13054&quot;&gt;&lt;del&gt;LU-13054&lt;/del&gt;&lt;/a&gt; ldiskfs: split htree_lock as separate patch&lt;/tt&gt;&quot; split the ect4-pdirops patch into a separate ext4-htree-lock patch, for a net reduction of 6500 lines of patches.&lt;/p&gt;</comment>
                            <comment id="280814" author="simmonsja" created="Sun, 27 Sep 2020 21:01:06 +0000"  >&lt;p&gt;Track the parallel VFS + ext4 lookup for upstream: &lt;a href=&quot;https://patchwork.kernel.org/patch/10695037/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://patchwork.kernel.org/patch/10695037/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="337112" author="adilger" created="Thu, 9 Jun 2022 01:58:33 +0000"  >&lt;p&gt;The data-in-dirent patch was being discussed for upstream inclusion for 64-but inode support, but eventually that was not accepted because the 64-bit inode patch was only partially tested (ie. it built and didn&apos;t break 32-bit inodes, but had code and testing gaps for actual 64-bit inode numbers).&lt;/p&gt;

&lt;p&gt;Landing the dirdata patch has now become more complex because the &quot;fscrypt+case-insensitive&quot; features are now storing extra information after the name in the dirent. This &lt;em&gt;would&lt;/em&gt; have been a perfect case to use dirdata and get it included, except Google had already started using this in Android and didn&apos;t want to update the format, so there needs to be additional compatibility added for this case. &lt;/p&gt;

&lt;p&gt;An agreed-upon proposal to get dirdata accepted without the Lustre kernel dependency is to add a dedicated test ioctl interface to store dirdata in directory entries, and confirm that it is being handled properly (eg. across rename, with e2fsck, etc).  For compatibility with Lustre, this could store the &quot;&lt;tt&gt;inode|generation&lt;/tt&gt;&quot; into the Lustre FID slot, since this is equivalent to an IGIF FID, and is also easy to verify later. &lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="28276">LU-6141</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="57570">LU-13054</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="12641">LU-908</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="27930">LU-6030</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="79992">LU-17423</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="46931">LU-9724</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56278">LU-12511</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|hzx5tr:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>17396</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>