<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:11: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-940] Many places in the test framework issue 3 syncs [sync; sync; sync] do flush the filesystem before [for example] failover.</title>
                <link>https://jira.whamcloud.com/browse/LU-940</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Many places in the test framework issue 3 syncs &lt;span class=&quot;error&quot;&gt;&amp;#91;sync; sync; sync&amp;#93;&lt;/span&gt; do flush the filesystem before &lt;span class=&quot;error&quot;&gt;&amp;#91;for example&amp;#93;&lt;/span&gt; failover.&lt;/p&gt;

&lt;p&gt;This 3 sync strategy should not be required, is not what a user would do and so is either unneccessary or hides unlying sync issues.&lt;/p&gt;

&lt;p&gt;The multiple calls to sync should be remove.&lt;/p&gt;</description>
                <environment></environment>
        <key id="12714">LU-940</key>
            <summary>Many places in the test framework issue 3 syncs [sync; sync; sync] do flush the filesystem before [for example] failover.</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="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="10100">Low Priority</resolution>
                                        <assignee username="wc-triage">WC Triage</assignee>
                                    <reporter username="chris">Chris Gearing</reporter>
                        <labels>
                    </labels>
                <created>Mon, 19 Dec 2011 08:08:47 +0000</created>
                <updated>Wed, 28 Feb 2018 20:21:10 +0000</updated>
                            <resolved>Wed, 28 Feb 2018 20:21:10 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>1</watches>
                                                                            <comments>
                            <comment id="28736" author="tappro" created="Wed, 15 Feb 2012 09:58:18 +0000"  >&lt;p&gt;I thought about the same when saw syncs before failover are being done implicitly. This is bad practice because it makes our tests working fine, but nobody will do sync on customer clusters before reboot, so we are getting green test results by moving problems on customer side which is not acceptable. Our green tests make just no sense if bugs are hidden.&lt;/p&gt;

&lt;p&gt;Meanwhile there is 3 sync in replay-barrier which is artificial construction just to make sure all data is on disk before we continue. It is used mostly in our unit tests to check various recovery cases with strong operation ordering and state, so it is required to have syncs there otherwise operation state is undefined - committed or not.&lt;/p&gt;</comment>
                            <comment id="63945" author="spimpale" created="Fri, 9 Aug 2013 10:20:04 +0000"  >&lt;p&gt;There were a couple of places in test framework which used 3 syncs in a row.&lt;br/&gt;
I have fixed those in this patch (&lt;a href=&quot;http://review.whamcloud.com/#/c/7280&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/7280&lt;/a&gt;)&lt;/p&gt;</comment>
                            <comment id="63947" author="spimpale" created="Fri, 9 Aug 2013 10:25:29 +0000"  >&lt;p&gt;I somehow missed Mikhail&apos;s comment above.&lt;br/&gt;
Since the 3 sync strategy in replay_barrier is an artificial construction, this patch is not required. &lt;br/&gt;
Abandoned it.&lt;/p&gt;</comment>
                    </comments>
                    <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|hzvxlz:</customfieldvalue>

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