<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 01:34:05 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-3457] After power failure 1 OST failed to come up.</title>
                <link>https://jira.whamcloud.com/browse/LU-3457</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>
&lt;p&gt;We experienced a power failure last night due to winds slapping two high tension lines together and while restoring everything to working order one OST (luckily only one) would not mount. When I ran fsck on the file system, basically it put EVERYTHING in lost+found and complained loudly about multiply-claimed blocks. &lt;/p&gt;

&lt;p&gt;When the fsck conpleted, I ran ll_recover_lost_found_objs that restored all but ~84MB and after recreating the CONFIGS directory in the root and moving the CONFIGS files back to that directory. I re-ran fsck until no more fixes were made and was able to get OST information via tunefs.lustre and mount the file system. In all about a dozen inodes were affected and I think all but maybe three were not recovered. I think these file were the health check and quota files. (After bringing the file system back online lfs quota -u &amp;lt;file system&amp;gt; failed saying it wasn&apos;t enabled. I am in the process of doing a lfs quotacheck now.)&lt;/p&gt;

&lt;p&gt;In any event these fsck messages a ones that I&apos;ve never seen before and the message that is most concerning is the &quot;boot loader inode&quot; message. As I said, after the first fsck and mounting ldiskfs there was only the lost+found directory. Since we are still in a recovery mode I wanted to find out if there is any thing that I am missing or should have done or do with this particular OST or if there are any concerns that I should be on the lookout for before returning the file system to production. Unfortunately this occurred on a system that prevents me from providing any logs (the output below is hand typed).&lt;/p&gt;

&lt;p&gt;TIA&lt;/p&gt;

&lt;p&gt;####&lt;br/&gt;
There is 1 inodes containing multiply-clamed blocks&lt;/p&gt;

&lt;p&gt;File &amp;lt;The boot loader inode&amp;gt; (inode $5 mod time Mon Jun 10 13:32:09 2013)&lt;br/&gt;
  has 5632 multiply-claimed block(s) shared with one file.&lt;br/&gt;
        /O/0/d28/6574428 (inode %1624725, mod time Mon Jun 10 18:23:10 2013)&lt;br/&gt;
Clone multiply-claimed blocks? yes&lt;/p&gt;

&lt;p&gt;clone_file_block: internal error: can&apos;t find dup_blk for 3357776535&lt;/p&gt;

&lt;p&gt;clone_file_block: internal error: can&apos;t find dup_blk for 3357776535&lt;/p&gt;

&lt;p&gt;File O/0/d28/6574428 (inode %1624725, mod time Mon Jun 10 18:23:10 2013)&lt;br/&gt;
  has 5632 multiply-claimed block(s) shared with one file.&lt;br/&gt;
        &amp;lt;The boot loader inode&amp;gt; (inode $5 mod time Mon Jun 10 13:32:09 2013)&lt;br/&gt;
Multiply-claimed blocks already reassigned or cloned.&lt;br/&gt;
####&lt;/p&gt;

</description>
                <environment>TOSS 2.0 Lustre 2.1, DDN SFA10k </environment>
        <key id="19373">LU-3457</key>
            <summary>After power failure 1 OST failed to come up.</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</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="adilger">Andreas Dilger</assignee>
                                    <reporter username="jamervi">Joe Mervini</reporter>
                        <labels>
                    </labels>
                <created>Wed, 12 Jun 2013 00:08:40 +0000</created>
                <updated>Wed, 10 Jul 2013 16:30:55 +0000</updated>
                            <resolved>Wed, 10 Jul 2013 16:30:55 +0000</resolved>
                                                                        <due></due>
                            <votes>0</votes>
                                    <watches>5</watches>
                                                                            <comments>
                            <comment id="60403" author="pjones" created="Wed, 12 Jun 2013 00:16:21 +0000"  >&lt;p&gt;Andreas&lt;/p&gt;

&lt;p&gt;Could you please advise Sandia?&lt;/p&gt;

&lt;p&gt;Thanks&lt;/p&gt;

&lt;p&gt;Peter&lt;/p&gt;</comment>
                            <comment id="60409" author="green" created="Wed, 12 Jun 2013 00:40:30 +0000"  >&lt;p&gt;Seems objects directory was damaged and also some inode tables, but then I see a full path name in your hand-typed message, so based on that it should not got everything into lost_found.&lt;/p&gt;

&lt;p&gt;In any case if you&apos;ve got most everything back with  ll_recover_lost_found_objs, then you probably cannot do much more.&lt;/p&gt;

&lt;p&gt;Please note that there still could be file content damage in files that fsck cannot correct for obvious reasons, there&apos;s no easy way to find it, so I&apos;d treat all objects on that OST as suspect.&lt;br/&gt;
If you happen to keep checksums or something like that for files on your FS, now might be a good time to verify them to see actual file content affected.&lt;/p&gt;</comment>
                            <comment id="60418" author="adilger" created="Wed, 12 Jun 2013 03:41:11 +0000"  >&lt;p&gt;I agree with Oleg - &lt;tt&gt;ll_recover_lost_found_objs&lt;/tt&gt; did its job and rebuilt the filesystem tree.  It seems that the beginning of the filesystem must have been corrupted somehow, but I don&apos;t think any further recovery is possible at this point.&lt;/p&gt;

&lt;p&gt;The &quot;boot loader inode&quot; is just one of the reserved inodes at the start of the filesystem (#5), so it was overwritten by garbage along with the root directory (#2) and some of the object directories (which is what caused everything to end up in &lt;tt&gt;lost+found&lt;/tt&gt;).&lt;/p&gt;</comment>
                            <comment id="62035" author="jamervi" created="Wed, 10 Jul 2013 16:28:46 +0000"  >&lt;p&gt;Feel free to close this ticket.&lt;/p&gt;</comment>
                            <comment id="62036" author="pjones" created="Wed, 10 Jul 2013 16:30:55 +0000"  >&lt;p&gt;ok - thanks Joe!&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|hzvt33:</customfieldvalue>

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