<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:33:43 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-10288] LFSCK support for mirrored files</title>
                <link>https://jira.whamcloud.com/browse/LU-10288</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;PFID EA should already have enough information to restore mirrored files in a catastrophic failure where the metadata on the MDT is lost. After FLR is introduced, the &lt;tt&gt;filter_fid&lt;/tt&gt; contains the following information:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;struct ost_layout {                                                             
        __u32   ol_stripe_size;                                                 
        __u32   ol_stripe_count;                                                
        __u64   ol_comp_start;                                                  
        __u64   ol_comp_end;                                                    
        __u32   ol_comp_id;                                                     
} __attribute__((packed)); 

struct filter_fid {                                                             
        struct lu_fid           ff_parent;                                      
        struct ost_layout       ff_layout;                                      
        __u32                   ff_layout_version;                              
        __u32                   ff_range; /* range of layout version that       
                                           * write are allowed */               
} __attribute__((packed)); 
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;And component ID is composed of &lt;tt&gt;SEQ_ID&lt;/tt&gt; and &lt;tt&gt;MIRROR_ID&lt;/tt&gt; as follows:&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;#define SEQ_ID_MAX              0x0000FFFF                                      
#define SEQ_ID_MASK             SEQ_ID_MAX                                      
&lt;span class=&quot;code-comment&quot;&gt;/* bit 30:16 of lcme_id is used to store mirror id */&lt;/span&gt;                           
#define MIRROR_ID_MASK          0x7FFF0000                                      
#define MIRROR_ID_SHIFT         16  
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;With the above information, the LFSCK just needs to use FID to identify the OST objects that belong to the same file, and use mirror ID, the upper 16 bit in component ID, to identify the components that belong to the same mirror, and the use SEQ ID and &lt;tt&gt;ol_comp_start, ol_comp_end&lt;/tt&gt; in &lt;tt&gt;ost_layout&lt;/tt&gt; to compose components in one mirror.&lt;/p&gt;

&lt;p&gt;The problem is how to identify and restore stale components. By checking the information of &lt;tt&gt;ff_layout_version&lt;/tt&gt; and &lt;tt&gt;ff_range&lt;/tt&gt;, it should be easy to know whether the file was being written at the time of failure; but it seems to be difficult to identify if a previous resync was complete. Therefore, we probably need more information for this purpose.&lt;/p&gt;</description>
                <environment></environment>
        <key id="49453">LU-10288</key>
            <summary>LFSCK support for mirrored files</summary>
                <type id="4" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11310&amp;avatarType=issuetype">Improvement</type>
                                            <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="jay">Jinshan Xiong</reporter>
                        <labels>
                            <label>FLR2</label>
                    </labels>
                <created>Mon, 27 Nov 2017 22:18:02 +0000</created>
                <updated>Mon, 6 Aug 2018 14:51:07 +0000</updated>
                            <resolved>Mon, 6 Aug 2018 14:51:07 +0000</resolved>
                                                    <fixVersion>Lustre 2.12.0</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>8</watches>
                                                                            <comments>
                            <comment id="216762" author="jgmitter" created="Tue, 19 Dec 2017 18:58:16 +0000"  >&lt;p&gt;Moved out from under &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9771&quot; title=&quot;FLR1: Landing tickets for File Level Redundancy Phase 1&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9771&quot;&gt;&lt;del&gt;LU-9771&lt;/del&gt;&lt;/a&gt; as it belongs to FLR2&lt;/p&gt;</comment>
                            <comment id="228817" author="yong.fan" created="Wed, 30 May 2018 01:10:56 +0000"  >&lt;p&gt;Consider the DoM case, things will be more complex. The DoM data is directly attached to the MDT-object, if the LOV EA corrupted, we have to re-calculate the DoM boundary from its subsequent component range. But the component ID may be discontinuous, so during the LOV EA rebuilding, we have to guess the end boundary of DoM, and even if after the LFSCK, we may still not know exactly which one is the second component for the mirror. So we may have no way to recover the LOV EA exactly the same as before the corruption.&lt;/p&gt;</comment>
                            <comment id="228818" author="yong.fan" created="Wed, 30 May 2018 01:15:35 +0000"  >&lt;p&gt;Another issue is about how to detect whether a file is DoM case or not if its LOV EA corrupted. Currently, the LFSCK can check the MDT-object&apos;s size on the MDT, if it is non-zero, then it will DoM case; otherwise, it can be handled as any case. But such way will be broken once SoM related feature is introduced. So we some more reliable mechanism.&lt;/p&gt;</comment>
                            <comment id="228819" author="adilger" created="Wed, 30 May 2018 02:32:31 +0000"  >&lt;blockquote&gt;
&lt;p&gt;Another issue is about how to detect whether a file is DoM case or not if its LOV EA corrupted. Currently, the LFSCK can check the MDT-object&apos;s size on the MDT, if it is zero, then it will DoM case; otherwise, it can be handled as any case.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;Wouldn&apos;t it be true that a &lt;b&gt;non&lt;/b&gt;&lt;del&gt;zero size and non-zero blocks means it is DoM?  (Note there may be upgraded 1.8 MDTs that still store total file size in inode&lt;/del&gt;&amp;gt;i_size that we should probably fix)&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;But such way will be broken once SoM related feature is introduced. So we some more reliable mechanism.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;The SOM feature will store the file size/blocks in a separate &quot;som&quot; xattr, so it should not interfere with DoM detection. &lt;/p&gt;</comment>
                            <comment id="228824" author="yong.fan" created="Wed, 30 May 2018 04:45:03 +0000"  >&lt;p&gt;Yes, the DoM is for non-zero case. I am not sure whether we still have customer to use 1.8 formatted file which MDT-object&apos;s size is not zero. If yes, then its LOV EA is non-PFL mode, so we can know it is not DoM case; if the 1.8 file lost its LOV EA, then its OST-object will declare as orphan, but 1.8 OST-object has no component ID, so the LFSCK should know it is for non-DoM file.&lt;/p&gt;</comment>
                            <comment id="229405" author="yong.fan" created="Mon, 11 Jun 2018 14:10:44 +0000"  >&lt;p&gt;The DoM related issue will be handled via another independent ticket &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11081&quot; title=&quot;LFSCK support for DoM file&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11081&quot;&gt;LU-11081&lt;/a&gt;. This ticket will only process mirrored file without DoM component.&lt;/p&gt;</comment>
                            <comment id="229483" author="gerrit" created="Wed, 13 Jun 2018 07:42:09 +0000"  >&lt;p&gt;Fan Yong (fan.yong@intel.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/32705&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/32705&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-10288&quot; title=&quot;LFSCK support for mirrored files&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-10288&quot;&gt;&lt;del&gt;LU-10288&lt;/del&gt;&lt;/a&gt; lfsck: layout LFSCK for mirrored file&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 276b919a8b5f23c6e8d75c5907c58b760c87657c&lt;/p&gt;</comment>
                            <comment id="231499" author="gerrit" created="Mon, 6 Aug 2018 14:34:43 +0000"  >&lt;p&gt;Oleg Drokin (green@whamcloud.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/32705/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/32705/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-10288&quot; title=&quot;LFSCK support for mirrored files&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-10288&quot;&gt;&lt;del&gt;LU-10288&lt;/del&gt;&lt;/a&gt; lfsck: layout LFSCK for mirrored file&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 36ba989752c62cc76b06089373fcd6cec6da9008&lt;/p&gt;</comment>
                            <comment id="231519" author="pjones" created="Mon, 6 Aug 2018 14:51:07 +0000"  >&lt;p&gt;Landed for 2.12&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|hzzob3:</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>
                                                                                                                                                                                                                                                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>