<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:47:01 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-4923] lfsck statistics are inconsistent</title>
                <link>https://jira.whamcloud.com/browse/LU-4923</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;An existing filesystem on a 2.4.2 MDT that was previously upgraded from Lustre 2.1, 1.8, 1.6, has about 1.8M inodes in use:&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;lfs df -i
UUID                      Inodes       IUsed       IFree IUse% Mounted on
myth-MDT0000_UUID        2621440     1837764      783676  70% /myth[MDT:0]
myth-OST0000_UUID         921856      315326      606530  34% /myth[OST:0]
myth-OST0001_UUID         475168      168933      306235  36% /myth[OST:1]
myth-OST0002_UUID         715264      585400      129864  82% /myth[OST:2]
myth-OST0003_UUID         688128      600027       88101  87% /myth[OST:3]
myth-OST0004_UUID         921856      118677      803179  13% /myth[OST:4]

filesystem summary:      2621440     1837764      783676  70% /myth
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Running &quot;&lt;tt&gt;lctl lfsck_start -t namespace -M myth-MDT0000&lt;/tt&gt;&quot;  it shows the following statistics on completion:&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;lctl get_param mdd.*.lfsck_namespace
mdd.myth-MDT0000.lfsck_namespace=
name: lfsck_namespace
magic: 0xa0629d03
version: 2
status: completed
flags: scanned-once,inconsistent
param: (null)
time_since_last_completed: 3 seconds
time_since_latest_start: 126 seconds
time_since_last_checkpoint: 3 seconds
latest_start_position: 13, N/A, N/A
last_checkpoint_position: 2621440, N/A, N/A
first_failure_position: N/A, N/A, N/A
checked_phase1: 3688305
checked_phase2: 222
updated_phase1: 1762893
updated_phase2: 147
failed_phase1: 0
failed_phase2: 0
dirs: 92332
M-linked: 833
nlinks_repaired: 0
lost_found: 0
success_count: 3
run_time_phase1: 122 seconds
run_time_phase2: 0 seconds
average_speed_phase1: 30232 items/sec
average_speed_phase2: 222 objs/sec
real-time_speed_phase1: N/A
real-time_speed_phase2: N/A
current_position: N/A
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;The number of inodes reported &quot;&lt;tt&gt;checked_phase1&lt;/tt&gt;&quot; is about 2x the number of actual inodes in the filesystem, which looks like a bug if LFSCK is checking each inode twice.&lt;/p&gt;

&lt;p&gt;Also, the &quot;updated_phase1&quot; value is always showing almost all of the inodes are &quot;updated&quot;, even if LFSCK is run multiple times.  This seems like a possibly separate bug if this is caused by IGIF inodes, or other problems with older filesystems.&lt;/p&gt;</description>
                <environment></environment>
        <key id="24271">LU-4923</key>
            <summary>lfsck statistics are inconsistent</summary>
                <type id="7" iconUrl="https://jira.whamcloud.com/images/icons/issuetypes/task_agile.png">Technical task</type>
                            <parent id="23439">LU-4701</parent>
                                    <priority id="2" iconUrl="https://jira.whamcloud.com/images/icons/priorities/critical.svg">Critical</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="yong.fan">nasf</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                            <label>LFSCK</label>
                    </labels>
                <created>Thu, 17 Apr 2014 08:27:03 +0000</created>
                <updated>Tue, 11 Sep 2018 23:32:17 +0000</updated>
                            <resolved>Fri, 9 May 2014 14:55:19 +0000</resolved>
                                    <version>Lustre 2.4.2</version>
                                    <fixVersion>Lustre 2.6.0</fixVersion>
                    <fixVersion>Lustre 2.11.0</fixVersion>
                    <fixVersion>Lustre 2.10.6</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                            <comments>
                            <comment id="81813" author="adilger" created="Thu, 17 Apr 2014 08:36:24 +0000"  >&lt;p&gt;Note that I haven&apos;t tested this on master or b2_5, but it definitely seems like a bug in 2.4.&lt;/p&gt;</comment>
                            <comment id="81859" author="adilger" created="Thu, 17 Apr 2014 18:01:55 +0000"  >&lt;p&gt;Fan Yong, could you please comment on whether this is just an LFSCK accounting problem (e.g. double counting of checked inodes), or if it is actually checking each inode twice (slowing everything down)?  Also, is it correct that LFSCK is actually trying to repair every inode in my filesystem every time it is run, or am I misunderstanding what &quot;updated_phase1: 1762893&quot; means?&lt;/p&gt;</comment>
                            <comment id="81899" author="yong.fan" created="Thu, 17 Apr 2014 23:21:27 +0000"  >&lt;p&gt;The &quot;checked_phase1&quot; counts:&lt;br/&gt;
1) the objects found during the otable-based iteration +&lt;br/&gt;
2) the name entries found during the namespace-based directory traversal.&lt;/p&gt;

&lt;p&gt;So it is almost equal to double of the real inodes count.&lt;/p&gt;

&lt;p&gt;The &quot;M-linked&quot; is the sum of the nlink of every multiple-linked object.&lt;/p&gt;

&lt;p&gt;S if a file has been scanned N times, then it will counted as N times, it seems not well understood for others. What is your expected result?&lt;/p&gt;

&lt;p&gt;As for the everything has been repaired every time, it should be a bug. I will investigate and fix it.&lt;/p&gt;</comment>
                            <comment id="81912" author="yong.fan" created="Fri, 18 Apr 2014 03:36:30 +0000"  >&lt;p&gt;Andreas, would you please to verify that whether you have enabled DIRDATA on your 2.4.2 system or not? If not, then it is normal that &quot;updated_phase1&quot; shows something have been repaired every time; otherwise, it is better to offer me the -1 log on your MDS when run namespace LFSCK. Thanks!&lt;/p&gt;

&lt;p&gt;As for the &quot;checked_phase1&quot;, which value is preferred: the real objects count? or the times of objects have been scanned (which is the current show). Because we use otable-based iteration + directory traversal, then almost every object will be scanned twice.&lt;/p&gt;</comment>
                            <comment id="82015" author="adilger" created="Sat, 19 Apr 2014 08:35:45 +0000"  >&lt;p&gt;I think if there are two different checks being done on the inode then they should be counted in two different counters. &lt;/p&gt;

&lt;p&gt;Similarly, for the updated_phase1 number, it would be better to have something like &quot;missing_lma:&quot; or &quot;missing_fid_in_dirent:&quot; or similar, so there is an easier way to track what is wrong with the filesystem. I don&apos;t mind to keep a summary counter for the whole pass, but it would be good to keep a counter for each type of corruption found and fixed. &lt;/p&gt;</comment>
                            <comment id="82016" author="adilger" created="Sat, 19 Apr 2014 08:51:15 +0000"  >&lt;p&gt;I checked, and you are correct that I did not have DIRDATA enabled on my system. I think in the Lustre 2.6 and later systems it could print a single warning at mount time that this should be enabled on MDTs that do not have it. &lt;/p&gt;</comment>
                            <comment id="82028" author="yong.fan" created="Sun, 20 Apr 2014 00:44:32 +0000"  >&lt;p&gt;Here is the patch:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://review.whamcloud.com/10030&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/10030&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="83626" author="yong.fan" created="Fri, 9 May 2014 14:55:19 +0000"  >&lt;p&gt;The patch has been landed to master.&lt;/p&gt;</comment>
                            <comment id="210000" author="gerrit" created="Fri, 29 Sep 2017 21:27:37 +0000"  >&lt;p&gt;Andreas Dilger (andreas.dilger@intel.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/29274&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/29274&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4923&quot; title=&quot;lfsck statistics are inconsistent&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4923&quot;&gt;&lt;del&gt;LU-4923&lt;/del&gt;&lt;/a&gt; osd-ldiskfs: dirdata is not needed on MGS&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 79e96c70256e67e81e8d549309483bf4768f1233&lt;/p&gt;</comment>
                            <comment id="211757" author="gerrit" created="Tue, 24 Oct 2017 07:18:07 +0000"  >&lt;p&gt;Oleg Drokin (oleg.drokin@intel.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/29274/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/29274/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4923&quot; title=&quot;lfsck statistics are inconsistent&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4923&quot;&gt;&lt;del&gt;LU-4923&lt;/del&gt;&lt;/a&gt; osd-ldiskfs: dirdata is not needed on MGS&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 383ef1a93b67778704c009aa3c1b0e2c15a5bb76&lt;/p&gt;</comment>
                            <comment id="231663" author="gerrit" created="Wed, 8 Aug 2018 18:56:42 +0000"  >&lt;p&gt;Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/32961&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/32961&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4923&quot; title=&quot;lfsck statistics are inconsistent&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4923&quot;&gt;&lt;del&gt;LU-4923&lt;/del&gt;&lt;/a&gt; osd-ldiskfs: dirdata is not needed on MGS&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: b2_10&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: c16c32f65da284d5d7400fe10a53ea5974a664fa&lt;/p&gt;</comment>
                            <comment id="233359" author="gerrit" created="Tue, 11 Sep 2018 22:17:57 +0000"  >&lt;p&gt;John L. Hammond (jhammond@whamcloud.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/32961/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/32961/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-4923&quot; title=&quot;lfsck statistics are inconsistent&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-4923&quot;&gt;&lt;del&gt;LU-4923&lt;/del&gt;&lt;/a&gt; osd-ldiskfs: dirdata is not needed on MGS&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: b2_10&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 7e81206793b02918e32e4fe19d54e6bfaee6c542&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|hzwkgn:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>13609</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>