<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 03:18:07 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-15414] FLDB mirroring</title>
                <link>https://jira.whamcloud.com/browse/LU-15414</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;For reliability, it would be desirable to replicate the FLDB file across multiple MDTs, in case the FLDB file on MDT0000 is lost or corrupted. Since the FLDB itself is changing very rarely (only when new MDTs or OSTs are added to the filesystem, or 4B SEQ numbers have been allocated by one target), there should not be any noticeable performance overhad from having multiple mirrors.&lt;/p&gt;

&lt;p&gt;Since the FLDB will almost always be in sync across MDTs, it would be possible for the clients/servers to contact any MDT with an FLDB replica, and only query the MDT0000 FLDB copy if the requested SEQ number could not be located on the other MDT.&lt;/p&gt;

&lt;p&gt;When there are many MDTs, it may be impractical to have an FLDB copy on &lt;b&gt;every&lt;/b&gt; MDT in the filesystem, so it makes sense to (deterministically) have FLDB copies only on a subseet of MDTs, such as having backups on MDT0001, MDT0003, MDT0005, MDT0007, MDT0009, MDTxxxx where x=3 &lt;sup&gt;n&lt;/sup&gt; , 5 &lt;sup&gt;n&lt;/sup&gt; , 7 &lt;sup&gt;n&lt;/sup&gt; (like ext4 superblock copies). This would provide one backup for 2 MDTs, 2 backups for 4 MDTs, 3 for 8 MDTs, ..., up to 23 replicas with 65536 MDTs. One drawback of this mechanism is that the replicas may not be available if the MDTs are not densely numbered, but that is a very uncommon configuration, and almost certainly MDT0000 and MDT0001 should be available.&lt;/p&gt;</description>
                <environment></environment>
        <key id="67826">LU-15414</key>
            <summary>FLDB mirroring</summary>
                <type id="4" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</priority>
                        <status id="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="wc-triage">WC Triage</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                            <label>LMR</label>
                    </labels>
                <created>Thu, 6 Jan 2022 11:00:24 +0000</created>
                <updated>Sun, 12 Mar 2023 10:17:13 +0000</updated>
                                                                                <due></due>
                            <votes>0</votes>
                                    <watches>2</watches>
                                                                            <comments>
                            <comment id="323433" author="adilger" created="Fri, 21 Jan 2022 05:17:25 +0000"  >&lt;p&gt;It may be enough that each MDT and OST always fetches a full copy of the FLDB from MDT0000 and stores it locally.  That would make it trivial to manually copy the &quot;&lt;tt&gt;fld&lt;/tt&gt;&quot; file to a failed MDT0000, or (better) do FLDB lookups on another server to recover at mount time from another server.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="24195">LU-4898</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="67924">LU-15437</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_10092" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>EX-4404</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                    <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|i02dsv:</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>