<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:07:00 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-7217] sanity-lfsck test_23b hangs on START_NAMESPACE</title>
                <link>https://jira.whamcloud.com/browse/LU-7217</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Configuration : 4 node setup : 1 MDS/ 1 OSS/ 2 clients&lt;br/&gt;
Release&lt;br/&gt;
Server 2.7.60&lt;br/&gt;
Client 2.7.60&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;
stdout.log
Total allocated inode limit: 0, total allocated block limit: 0

== sanity-lfsck test 23c: LFSCK can repair dangling name entry (3) == 08:02:38 (1443427358)
#####
The objectA has multiple hard links, one of them corresponding
to the name entry_B. But there is something wrong for the name
entry_B and cause entry_B to references non-exist object_C.
In the first-stage scanning, the LFSCK will think the entry_B
as dangling, and re-create the lost object_C. And then others
modified the re-created object_C. When the LFSCK comes to the
second-stage scanning, it will find that the former re-creating
object_C maybe wrong and try to replace the object_C with the
real object_A. But because object_C has been modified, so the
LFSCK cannot replace it.
#####
Inject failure stub on MDT0 to simulate dangling name entry
fail_loc=0x1621
fail_loc=0
&apos;ls&apos; should fail because of dangling name entry
fail_val=10
fail_loc=0x1602
Trigger namespace LFSCK to find out dangling name entry
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
        <key id="32346">LU-7217</key>
            <summary>sanity-lfsck test_23b hangs on START_NAMESPACE</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="6">Not a Bug</resolution>
                                        <assignee username="yong.fan">nasf</assignee>
                                    <reporter username="parinay">parinay v kondekar</reporter>
                        <labels>
                    </labels>
                <created>Mon, 28 Sep 2015 11:01:42 +0000</created>
                <updated>Tue, 29 Sep 2015 14:05:57 +0000</updated>
                            <resolved>Tue, 29 Sep 2015 14:05:56 +0000</resolved>
                                    <version>Lustre 2.8.0</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                            <comments>
                            <comment id="128646" author="jgmitter" created="Mon, 28 Sep 2015 17:30:18 +0000"  >&lt;p&gt;Hi Fan Yong,&lt;br/&gt;
Can you look at this issue?&lt;br/&gt;
Thanks.&lt;br/&gt;
Joe&lt;/p&gt;</comment>
                            <comment id="128739" author="yong.fan" created="Tue, 29 Sep 2015 14:04:27 +0000"  >&lt;p&gt;According to the given log, I found that the unfinished test is test_23c, not test_23b. In the test_23c, we inject some stub to delay the LFSCK scanning:&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;est_23c() {
        echo &quot;#####&quot;
...

        #define OBD_FAIL_LFSCK_DELAY3           0x1602
        do_facet $SINGLEMDS $LCTL set_param fail_val=10 fail_loc=0x1602

        echo &quot;Trigger namespace LFSCK to find out dangling name entry&quot;
        $START_NAMESPACE -r -C ||
}
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Means that when hit the stub &quot;0x1602&quot; (for every item scanned during the 2nd phase), the LFSCK engine will sleep 10 seconds, then go ahead. So the whole LFSCK scanning looks very slow. But it is not hung there.&lt;/p&gt;

&lt;p&gt;Here is the MDS log:&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;00100000:10000000:0.0:1443429130.295422:0:7460:0:(lfsck_engine.c:1733:lfsck_assistant_engine()) lustre-MDT0000-osd: LFSCK assistant phase2 scan start, synced: rc = 0
00100000:10000000:0.0:1443429130.295430:0:7460:0:(lfsck_namespace.c:6121:lfsck_namespace_assistant_handler_p2()) lustre-MDT0000-osd: namespace LFSCK phase2 scan start
00100000:10000000:0.0:1443429130.295473:0:7460:0:(lfsck_namespace.c:5727:lfsck_namespace_scan_local_lpf()) lustre-MDT0000-osd: start to scan backend /lost+found
00000001:00020000:0.0:1443429130.295483:0:7460:0:(fail.c:133:__cfs_fail_timeout_set()) cfs_fail_timeout id 1602 sleeping for 10000ms
...
00000100:00100000:1.0:1443429133.621277:0:7029:0:(service.c:2121:ptlrpc_server_handle_request()) Handled RPC pname:cluuid+ref:pid:xid:nid:opc ll_mgs_0000:26a6aa1f-ae32-a150-7927-f6f66a7ef0c1+9:6277:x1513543135402544:12345-192.168.112.11@tcp:400 Request procesed in 35us (90us total) trans 0 rc 0/0
00000100:00100000:1.0:1443429133.621281:0:7029:0:(nrs_fifo.c:241:nrs_fifo_req_stop()) NRS stop fifo request from 12345-192.168.112.11@tcp, seq: 1561
Debug log: 18556 lines, 18556 kept, 0 dropped, 0 bad.
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;As we can see, the LFSCK engine hit the &quot;0x1602&quot; at time &quot;1443429130.295483&quot;, then went to sleep. As scheduled, it should be re-scheduled at the time &quot;1443429140.295483&quot;. But before such time, the log has been dumped (&quot;1443429133.xxxx&quot;), means the sleep time has not finished yet. So it is not a bug.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                            <attachment id="18992" name="23c.lctl.tgz" size="588585" author="parinay" created="Mon, 28 Sep 2015 11:01:42 +0000"/>
                    </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|hzxou7:</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>
                                                                                            <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>