<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:07:04 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-7225] change ladvise wire protocol for lockahead and future usage</title>
                <link>https://jira.whamcloud.com/browse/LU-7225</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;As a continuation of &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4931&quot; title=&quot;New feature of giving server/storage side advice of accessing file&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4931&quot;&gt;&lt;del&gt;LU-4931&lt;/del&gt;&lt;/a&gt; &quot;New feature of giving server/storage side advice of accessing file&quot; and &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4865&quot; title=&quot;osd-zfs: increase object block size dynamically as object grows&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4865&quot;&gt;&lt;del&gt;LU-4865&lt;/del&gt;&lt;/a&gt; &quot;osd-zfs: increase object block size dynamically as object grows&quot; it is useful to be able to specify the ZFS blocksize for a file directly from the client, so that the OSS doesn&apos;t have to guess at this itself.&lt;/p&gt;

&lt;p&gt;This can be done via the &quot;ladvise&quot; functionality.  One option is to pass the blocksize (a power-of-two value) along with the RANDOM hint on a newly-created file. This could use 8 bits of &lt;tt&gt;lla_padding&lt;/tt&gt; to store the log2 blocksize, giving a maximum blocksize up to 2^255 bytes.&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 lu_ladvise {
	__u64 lla_advice;
	__u64 lla_start;
	__u64 lla_end;
        __u8  lla_blockbits;
	__u8  lla_padding1;
	__u16 lla_padding2;
	__u32 lla_padding3;
};
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;It isn&apos;t clear if there are valid use cases for non-power-of-two RANDOM IO hints at the server, which would require using a different encoding (e.g. some multiple of a blocksize), since that could also be handled at the client by sending the underlying power-of-two blocksize.&lt;/p&gt;
</description>
                <environment></environment>
        <key id="32367">LU-7225</key>
            <summary>change ladvise wire protocol for lockahead and future usage</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="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="wc-triage">WC Triage</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                    </labels>
                <created>Mon, 28 Sep 2015 22:49:07 +0000</created>
                <updated>Wed, 26 Apr 2017 21:41:41 +0000</updated>
                            <resolved>Mon, 15 Aug 2016 22:22:34 +0000</resolved>
                                                    <fixVersion>Lustre 2.9.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>9</watches>
                                                                            <comments>
                            <comment id="154797" author="paf" created="Mon, 6 Jun 2016 18:23:36 +0000"  >&lt;p&gt;Andreas,&lt;/p&gt;

&lt;p&gt;For lock ahead, I needed to put a &apos;flags&apos; field in the individual lu_ladvise structs (using 32 bits of the padding).  Since that&apos;s already going to break compatibility slightly (with the as yet unreleased code), should we grow the size of the struct a little?  With the blockbits and the flags, we have only 24 bits left in the current struct.&lt;/p&gt;</comment>
                            <comment id="154802" author="adilger" created="Mon, 6 Jun 2016 18:46:27 +0000"  >&lt;p&gt;The other question is whether we need a __u64 for the advice type?  I&apos;d expect that this would be an enumeration of advice types, so having a __u8 or __u16 would be enough for the lu_advice field and the rest of that __u64 could be changed to other uses.&lt;/p&gt;

&lt;p&gt;In any case, changes to this structure need to be decided promptly, since feature freeze has passed, and we need to make any changes before the code freeze in 8 weeks.&lt;/p&gt;

&lt;p&gt;Li Xi, are there any sites already using the ladvise feature?  Are any of them using PPC or other big-endian systems?  If no big-endian machines are in use, then it should be safe to change the struct to keep &lt;tt&gt;lla_advice&lt;/tt&gt; first, and re-use the later bytes:&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;struct lu_ladvise {
	__u16 lla_advice;
        __u16 lla_paddingA;
        __u32 lla_paddingB;
	__u64 lla_start;
	__u64 lla_end;
        __u8  lla_blockbits;
	__u8  lla_padding1;
	__u16 lla_padding2;
	__u32 lla_padding3;
};
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</comment>
                            <comment id="154806" author="paf" created="Mon, 6 Jun 2016 19:07:32 +0000"  >&lt;p&gt;Agreed, that does seem very large for the advice...&lt;/p&gt;

&lt;p&gt;Still need the flags (or at least, I feel strongly we should have them - I don&apos;t actually need them now, so could do without if necessary), so what about:&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 lu_ladvise {
	__u16 lla_advice;
        __u8   lla_blockbits;
        __u8   lla_padding1;
        __u32 lla_flags;
	__u64 lla_start;
	__u64 lla_end;
	__u64 lla_padding2;
};
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Would that meet the alignment requirements you&apos;re describing?  Or do we need to put the new things at the end (as you did with blockbits above)?&lt;/p&gt;</comment>
                            <comment id="154823" author="paf" created="Mon, 6 Jun 2016 20:55:59 +0000"  >&lt;p&gt;Hmm - What about just putting the blockbits in &quot;start&quot;?  I mean, for that advice type, just use start as the block bits.  I still think we need flags, though.&lt;/p&gt;</comment>
                            <comment id="154840" author="adilger" created="Mon, 6 Jun 2016 22:16:33 +0000"  >&lt;p&gt;I was originally thinking of combining &quot;RANDOM&quot; advice with the blocksize of that random IO for a particular range, but I&apos;m not sure that makes sense anymore, since ladvise can combine multiple advices in a single RPC.  On the one hand, it should be fine to have a BLOCKSIZE advice with the block size in &quot;start&quot;, but that would preclude setting different block sizes for different file ranges (e.g. for PFL files with different storage types at different offsets).  I&apos;d be OK with the &lt;tt&gt;__u8 lla_blockbits&lt;/tt&gt; as you propose, or we could just make this a __u8 or __u16 &quot;lla_value16&quot; that can be used by different advice types as needed.&lt;/p&gt;

&lt;p&gt;I guess the same question is true about your lla_flags?  Is that generic for all the different advice types, or is it specific for the lockahead advice?  If the latter, we might consider making an lla_value32 field that can be used by different advice types instead of reserving the field only for the one type?  In general, flags are useful for a variety of things, so it might still make sense to keep it generic, but I&apos;d at least like to know what this is used for.&lt;/p&gt;</comment>
                            <comment id="154851" author="lixi" created="Tue, 7 Jun 2016 01:35:07 +0000"  >&lt;p&gt;I don&apos;t think ladvise is under use by any customer now, since we are still testing it. However, any protocol level change should be done in a few weeks, because this feature will be officially released in the near future.&lt;/p&gt;</comment>
                            <comment id="154910" author="paf" created="Tue, 7 Jun 2016 15:52:03 +0000"  >&lt;p&gt;I&apos;ll generate a patch with suggested protocol and interface changes.  It&apos;s going to be the same as in the lock ahead + ladvise patch - which I&apos;m close to posting - but I&apos;d hope to land it first, then rebase the lock ahead patch.&lt;/p&gt;</comment>
                            <comment id="154917" author="gerrit" created="Tue, 7 Jun 2016 16:13:38 +0000"  >&lt;p&gt;Patrick Farrell (paf@cray.com) uploaded a new patch: &lt;a href=&quot;http://review.whamcloud.com/20666&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/20666&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-7225&quot; title=&quot;change ladvise wire protocol for lockahead and future usage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-7225&quot;&gt;&lt;del&gt;LU-7225&lt;/del&gt;&lt;/a&gt; llite: ladvise struct proposal&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 2e8e328ee1752b3a934d96acee488fb4aa94e5e6&lt;/p&gt;</comment>
                            <comment id="154919" author="paf" created="Tue, 7 Jun 2016 16:14:16 +0000"  >&lt;p&gt;The above is just a sample, it&apos;s not even going to build.&lt;/p&gt;

&lt;p&gt;I will do the work to update lfs, etc, making this a full patch once we&apos;ve at least &lt;b&gt;mostly&lt;/b&gt; agreed on the struct changes.&lt;/p&gt;</comment>
                            <comment id="161935" author="gerrit" created="Mon, 15 Aug 2016 21:09:28 +0000"  >&lt;p&gt;Oleg Drokin (oleg.drokin@intel.com) merged in patch &lt;a href=&quot;http://review.whamcloud.com/20666/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/20666/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-7225&quot; title=&quot;change ladvise wire protocol for lockahead and future usage&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-7225&quot;&gt;&lt;del&gt;LU-7225&lt;/del&gt;&lt;/a&gt; llite: ladvise protocol changes&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 88fcc76b8dcd6febf780ad0503d725283e3c45c4&lt;/p&gt;</comment>
                            <comment id="161957" author="pjones" created="Mon, 15 Aug 2016 22:22:34 +0000"  >&lt;p&gt;Landed for 2.9&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10324">
                    <name>Cloners</name>
                                                                <inwardlinks description="is cloned by">
                                        <issuelink>
            <issuekey id="39676">LU-8591</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="24298">LU-4931</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="28460">LU-6179</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|hzxoyf:</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>
                                                                                                                                                                                                                                                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>