<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:12:36 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-1008] Improper error handling in trans_stop if some failure occurred during the transaction </title>
                <link>https://jira.whamcloud.com/browse/LU-1008</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;On master branch, the failure during one transaction is recorded through thandle::th_result in mdd_trans_stop(), but osd_trans_stop() neither transfer such errno down to lower layer JBD(2), nor does any error processing. So JBD(2) does not know what happened for the transaction.&lt;/p&gt;</description>
                <environment></environment>
        <key id="12912">LU-1008</key>
            <summary>Improper error handling in trans_stop if some failure occurred during the transaction </summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</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="2">Won&apos;t Fix</resolution>
                                        <assignee username="wc-triage">WC Triage</assignee>
                                    <reporter username="yong.fan">nasf</reporter>
                        <labels>
                    </labels>
                <created>Tue, 17 Jan 2012 10:23:43 +0000</created>
                <updated>Wed, 28 Feb 2018 20:24:26 +0000</updated>
                            <resolved>Wed, 28 Feb 2018 20:24:26 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                            <comments>
                            <comment id="26729" author="tappro" created="Tue, 17 Jan 2012 11:07:11 +0000"  >&lt;p&gt;Why jbd(2) should know about that? Can you explain more what is wrong now. The th_result is not to inform OSD about result of operation but to pass return code to the last_rcvd file which is written in mdt_txn_stop_cb(). Note that last_rcvd should be updated even if operation is failed so we still must finish started transaction and osd_trans_stop is doing that mo matter what is result of operation in MDD.&lt;/p&gt;</comment>
                            <comment id="26801" author="yong.fan" created="Wed, 18 Jan 2012 10:57:18 +0000"  >&lt;p&gt;When some failure occurred during the transaction, the transaction handle maybe aborted, maybe not, depends on where the failure occurred, the result is uncertain &amp;#8211; is_handle_aborted(). So even though we expect &quot;last_rcvd&quot; to be updated regardless of failures, it cannot be guaranteed.&lt;/p&gt;

&lt;p&gt;Under such case, we expect: all the former sub-operations should be rolled back, and the &quot;last_rcvd&quot; should be updated according to the failure. Rolling back step by step maybe failed also, which (double failures) is difficult to be processed. So it is relative simple that aborting the transaction explicitly (by osd_trans_stop()) without commit anything. And then restart the transaction for &quot;last_rcvd&quot; updating.&lt;/p&gt;


&lt;p&gt;It is just my idea. Please correct me if I miss anything.&lt;/p&gt;</comment>
                            <comment id="221973" author="adilger" created="Wed, 28 Feb 2018 20:24:26 +0000"  >&lt;p&gt;It is not possible to &quot;abort&quot; transactions at the JBD2 layer to &quot;undo&quot; them.  The only possible actions are to abort the whole journal and make the filesystem read-only, to manually undo the changes to the filesystem (if possible), or to leave the changes in place and fix them afterward with e2fsck/LFSCK (this should be avoided if possible).&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|hzw2o7:</customfieldvalue>

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