<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:48:44 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-5125] lu_object_attr() should return 0 for non-existing objects</title>
                <link>https://jira.whamcloud.com/browse/LU-5125</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&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;[09:45:54] John Hammond: Could someone explain the idea behind the lu_object_exists() assertion in lu_object_attr()?
[14:57:23] Alex Zhuravlev: I think that nobody should be trying to access attributes on non-existing object
[15:43:30] John Hammond: Yes, that part is clear.
[17:15:55] John Hammond: Uses of lu_object_attr() are fairly common and so this assertion seems to be hit in fairly safe looking code. Can you suggest how we can better avoid hitting it.
[17:16:27] John Hammond: Always check for existence right after object is found?
[17:16:57] John Hammond: Add lu_object_find_existing()?
[17:17:15] John Hammond: More disciplined LDLM usage?
[17:17:37] Alex Zhuravlev: we&apos;re discussing this and related stuff with Vitaly from Xx ..
[17:18:13] John Hammond: Just on gerrit? Or elsewhere?
[17:18:47] Alex Zhuravlev: a bit on skype, a bit in gerrit
[17:23:09] John Hammond: I understand what you say about non-existing objects. But from a stability perspective it just sounds like you&apos;re saying that people should only write code that makes sense. Can we have this function return 0 for non-existing objetcs?
[17:24:58] Alex Zhuravlev: well, this is a part of the discussion as well. there are different arguments here... I tend to think this is not very good if an object disappears when somebody else is using that, silently.
[17:25:51] Alex Zhuravlev: LBUG isn&apos;t a good thing, but I&apos;d think it&apos;s kind of easy to recovery from (relatively)
[17:26:25] Alex Zhuravlev: because nothing bad has been propagated to a disk or to another nodes.
[17:26:30] Alex Zhuravlev: not that I like LBUGs :)
[17:28:46] John Hammond: Respectfully MDT LBUGs are just not OK.
[17:29:08] Alex Zhuravlev: of course
[17:29:15] John Hammond: We can&apos;t keep using them to &quot;learn&quot; what we did wrong.
[17:29:24] Alex Zhuravlev: I disagree
[17:30:41] Alex Zhuravlev: learn &quot;before&quot; that something went wrong is much better than later, because in general the later, the more chances for bad consequences. especially then it comes to on-disk state, the clients, etc.
[17:33:35] John Hammond: Is there some chance that the discussions with Vitaly will yield a systematic way of avoiding this issue?
[17:34:04] Alex Zhuravlev: this is exactly what I&apos;m hoping for, with proper documentation
[17:35:35] John Hammond: Is it OK by you if I post the above conversation into a Jira issue?
[17:35:53] Alex Zhuravlev: sure
[17:37:55] John Hammond: OK. I&apos;ll give you a month. After that if there isn&apos;t something promising then I&apos;ll start pushing for returning 0.
[17:38:43] Alex Zhuravlev: fine. though frankly I don&apos;t think removing LBUG is the right way to go..
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
        <key id="24881">LU-5125</key>
            <summary>lu_object_attr() should return 0 for non-existing objects</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="6" iconUrl="https://jira.whamcloud.com/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="2">Won&apos;t Fix</resolution>
                                        <assignee username="jhammond">John Hammond</assignee>
                                    <reporter username="jhammond">John Hammond</reporter>
                        <labels>
                            <label>mdt</label>
                    </labels>
                <created>Fri, 30 May 2014 14:40:24 +0000</created>
                <updated>Wed, 19 Apr 2017 17:46:07 +0000</updated>
                            <resolved>Wed, 19 Apr 2017 17:46:07 +0000</resolved>
                                    <version>Lustre 2.6.0</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>8</watches>
                                                                            <comments>
                            <comment id="100717" author="adilger" created="Thu, 4 Dec 2014 18:48:19 +0000"  >&lt;p&gt;Alex, Vitaly, did you ever come to a conclusion about what to do in this case?  I agree with John that LBUG() is not a good form of error handling for cases that can actually happen (e.g. due to disk or network corruption, malicious clients, etc).  It should only be used for states that are impossible to hit except for code defects, and even then only if there is no good way to handle the error.&lt;/p&gt;</comment>
                            <comment id="102310" author="vitaly_fertman" created="Thu, 25 Dec 2014 19:37:19 +0000"  >&lt;p&gt;as I understand there are the following problems.&lt;/p&gt;

&lt;p&gt;1. the inode is not removed under the same transaction as unlink itself,&lt;br/&gt;
it is left until the final mdt_object_put-&amp;gt;lu_object_put-&amp;gt;osd_object_delete.&lt;/p&gt;

&lt;p&gt;several transactions means the operation is not atomic and inodes could be lost as the result.&lt;/p&gt;

&lt;p&gt;also, it may lead to some deadlocks like:&lt;br/&gt;
1 thread did trans_start and lookup for an object (i.e. mdd_rename-&amp;gt;mdd_rename_order),&lt;br/&gt;
when such an object is already removed and unhashed from ls_obj_hash, but inode is found and the thread is sitting in __wait_on_freeing_inode until it will get freed finally&lt;br/&gt;
2nd thread osd_object_delete-&amp;gt;iput marked the inode as FREEING but cannot start its transaction later.&lt;/p&gt;

&lt;p&gt;thus the left part is to move iput into osd_object_destroy() or around.&lt;/p&gt;

&lt;p&gt;2. all the operations works in the order object_find, object_lock (e.g. mdt_object_find_lock)&lt;br/&gt;
it means that found but not locked object can be unlinked in between and we will proceed&lt;br/&gt;
with dying object, what is illegal and may lead to some unexpected failures. better to change&lt;br/&gt;
the order to lock&amp;amp;find or add a sanity check for dying to the very end of object_lock.&lt;/p&gt;</comment>
                            <comment id="102311" author="vitaly_fertman" created="Thu, 25 Dec 2014 19:39:43 +0000"  >&lt;p&gt;this is what we discussed with Alex&lt;/p&gt;</comment>
                            <comment id="129725" author="gerrit" created="Wed, 7 Oct 2015 18:13:06 +0000"  >&lt;p&gt;John L. Hammond (john.hammond@intel.com) uploaded a new patch: &lt;a href=&quot;http://review.whamcloud.com/16750&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/16750&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-5125&quot; title=&quot;lu_object_attr() should return 0 for non-existing objects&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-5125&quot;&gt;&lt;del&gt;LU-5125&lt;/del&gt;&lt;/a&gt; lu: weaken assertion in lu_object_attr()&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 100aa3381ba76f4508fe182a018e54bcb6835998&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="25067">LU-5163</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="25407">LU-5285</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|hzwnfr:</customfieldvalue>

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