<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:38:12 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-3935] lfsck_start ignores -n/--dryrun</title>
                <link>https://jira.whamcloud.com/browse/LU-3935</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;Under Lustre 2.4.0, the lctl subcommand lfsck_start ignores the &lt;del&gt;n/&lt;/del&gt;-dryrun command.  For instance:&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 lfsck_start --dryrun on -M &amp;lt;MDT name&amp;gt;&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;That currently results in a real run of the OI scrub, and real modification to the filesystem, directly in contradiction to the documentation.&lt;/p&gt;

&lt;p&gt;I can understand if implementing that is going to take more work than we want to spend right now, but until the functionality is implemented the cmomand must return an error.  It should &lt;em&gt;not&lt;/em&gt; go ahead and make changes.&lt;/p&gt;

&lt;p&gt;Further, I am not particularly fond of the &quot;&amp;#45;&amp;#45;dryrun on&quot; syntax.  Unless there is a really, really good reason that &amp;#45;n and &amp;#45;&amp;#45;dryrun need to take on/off options, the command line interface should not be designed this way.  I think that -n/&amp;#45;&amp;#45;dryrun should be optionless.  (If they are present on the command line that means dryrun mode must be enabled.)&lt;/p&gt;

&lt;p&gt;That would match most sysadmins&apos; expected behavior.  Every other command I think that I have ever seen makes the dryrun command optionless.  For instance:&lt;/p&gt;

&lt;ul&gt;
	&lt;li&gt;fsck -N&lt;/li&gt;
	&lt;li&gt;rsync -n/&amp;#45;&amp;#45;dryrun&lt;/li&gt;
&lt;/ul&gt;
</description>
                <environment></environment>
        <key id="20920">LU-3935</key>
            <summary>lfsck_start ignores -n/--dryrun</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="1" iconUrl="https://jira.whamcloud.com/images/icons/priorities/blocker.svg">Blocker</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="morrone">Christopher Morrone</reporter>
                        <labels>
                    </labels>
                <created>Thu, 12 Sep 2013 06:36:21 +0000</created>
                <updated>Thu, 5 Jun 2014 19:14:16 +0000</updated>
                            <resolved>Tue, 24 Sep 2013 21:42:41 +0000</resolved>
                                    <version>Lustre 2.4.0</version>
                                    <fixVersion>Lustre 2.5.0</fixVersion>
                    <fixVersion>Lustre 2.4.2</fixVersion>
                                        <due></due>
                            <votes>1</votes>
                                    <watches>7</watches>
                                                                            <comments>
                            <comment id="66536" author="pjones" created="Thu, 12 Sep 2013 18:43:05 +0000"  >&lt;p&gt;Fan Yong&lt;/p&gt;

&lt;p&gt;Could you please comment on this one?&lt;/p&gt;

&lt;p&gt;thanks&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="66553" author="yong.fan" created="Thu, 12 Sep 2013 23:46:07 +0000"  >&lt;p&gt;It is not because of dryrun mode will need more time than expected. The key reason is that inode-table based iteration is a basic infrastructure for other up layer LFSCK components. We allow single LFSCK scanning to verify kinds of system inconsistency (such as OI mapping inconsistency, namespace inconsistency, MDT-OST layout inconsistency, MDT-MDT DNE inconsistency) to improve the efficiency. That is important for a very large system. If we does not fix the found OI mappings inconsistency during OI scrub, then other up layer LFSCK components will get invalid objects via the wrong OI mappings. Such invalidation may cannot be aware by up layer LFSCK components in time, as to cause some strange behaviour, and even incorrect reparation (or to be repaired).&lt;/p&gt;

&lt;p&gt;So it is NOT the &quot;--dryrun&quot; does not work, it works on up layer LFSCK components, such as &quot;lctl lfsck_start -M &amp;lt;MDT-device&amp;gt; -t namespace&quot;.&lt;/p&gt;</comment>
                            <comment id="66559" author="morrone" created="Fri, 13 Sep 2013 00:05:44 +0000"  >&lt;p&gt;I don&apos;t care how beneficial OI scrub is.&lt;/p&gt;

&lt;p&gt;The man page clearly states:&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;         -n, --dryrun &amp;lt;on|off&amp;gt;
              Perform a trial run with no changes made.
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;When I used it, there &lt;em&gt;were&lt;/em&gt; changes made.  That is not acceptable.&lt;/p&gt;

&lt;p&gt;So maybe you rename the option to &quot;--dont-do-as-much&quot; and clearly document what it does and does not alter about the scan&apos;s behavior.&lt;/p&gt;</comment>
                            <comment id="66560" author="yong.fan" created="Fri, 13 Sep 2013 00:32:56 +0000"  >&lt;p&gt;My current idea for that is&lt;/p&gt;

&lt;p&gt;1) If it is pure OI scrub without other LFSCK components scanning, then we should support &quot;--dryrun&quot;.&lt;/p&gt;

&lt;p&gt;2) If it is a combined running (OI scrub plus others) with &quot;--dryrun&quot; mode, then we should notice up layer LFSCK components to stopped/paused if found inconsistent OI mappings, and rescanning after OI scrub repaired inconsistent OI mappings.&lt;/p&gt;

&lt;p&gt;Andreas, what&apos;s your suggestion?&lt;/p&gt;</comment>
                            <comment id="66611" author="adilger" created="Fri, 13 Sep 2013 16:49:56 +0000"  >&lt;p&gt;I agree that &quot;--dry-run&quot; should not make any changes to the filesystem, so that should be fixed.&lt;/p&gt;

&lt;p&gt;The tricky part is that OI Scrub is supposed to start automatically at mount time to fix a broken/missing OI file in order to repair it promptly.&lt;/p&gt;</comment>
                            <comment id="67193" author="yong.fan" created="Sat, 21 Sep 2013 07:47:07 +0000"  >&lt;p&gt;The patch for dryrun mode OI scrub on master:&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://review.whamcloud.com/#/c/7720/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;http://review.whamcloud.com/#/c/7720/&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="67470" author="jlevi" created="Tue, 24 Sep 2013 21:42:41 +0000"  >&lt;p&gt;Patch landed to Master so closing ticket. If more work is needed let me know and I will reopen&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="24837">LU-5110</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="21256">LU-4058</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|hzw20n:</customfieldvalue>

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