<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 03:29:35 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-16738] Improve mount.lustre with many MGS NIDs</title>
                <link>https://jira.whamcloud.com/browse/LU-16738</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;When the MGS has multipe failover hosts, and each host has multiple NIDs, the mount command line can become excessively long:&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;# mount -t lustre 172.16.0.26@o2ib,172.16.0.27@o2ib:172.16.0.30@o2ib,172.16.0.31@o2ib:172.16.0.28@o2ib,172.16.0.29@o2ib:172.16.0.24@o2ib,172.16.0.25@o2ib:/testfs /lustre/testfs/client
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Not only is this very inconvenient to type and prone to error, but it is also unsightly in &quot;&lt;tt&gt;df&lt;/tt&gt;&quot; and &quot;&lt;tt&gt;mount&lt;/tt&gt;&quot; output because of the very long &quot;device&quot; name.  This will become &lt;b&gt;significantly&lt;/b&gt; worse once IPv6 NIDs are in use (each addresse will be about twice as long and hard to visually parse), and may even limit the number of NIDs that can be specified on the command-line due to the length.&lt;/p&gt;

&lt;p&gt;It is already possible (though uncommonly used, for some reason) to use DNS hostname lookup for the MGS NID in the case of TCP hostnames.  The &lt;tt&gt;mount.lustre&lt;/tt&gt; command will do DNS hostname resolution and pass the numeric NIDs to the kernel:&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;# mount -t lustre mgs-fs1-1a@o2ib,mgs-fs1-1b@oi2b:mgs-fs1-2a@o2ib,mgs-fs1-2b@o2ib:mgs-fs1-3a@o2ib,mgs-fs1-3b@oi2b:mgs-fs1-4a@oi2b,mgs-fs1-4b@o2ib:/testfs /lustre/testfs/client
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;This is an improvement, but still requires that all of the MGS hostnames are supplied at mount, but at least avoids the need for manually specifying all of the IP addresses.  If the network type is not specified, then it defaults to &lt;tt&gt;@tcp0&lt;/tt&gt;, but it is possible to use &lt;tt&gt;@o2ib&lt;/tt&gt; since this will also resolve to an IP address.&lt;/p&gt;

&lt;p&gt;A few improvements could be made to shorten this command-line:&lt;/p&gt;
&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;allow host or NID ranges to be specified:
&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;# mount -t lustre 172.16.0.[24-30/2]@o2ib,172.16.0.[25-31/2]@o2ib:/testfs /lustre/testfs/client
# mount -t lustre mgs-fs1-[1-4]a@o2ib,mgs-fs1-[1-4]b@o2ib:/testfs /lustre/testfs/client
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;This will be significantly less to type than the full NID list, but is somewhat opaque and would still need to be expanded internally by &lt;tt&gt;mount.lustre&lt;/tt&gt; to the full NID list for passing to the kernel.  The full list would still be visible in the &quot;&lt;tt&gt;mount&lt;/tt&gt;&quot; and &quot;&lt;tt&gt;df&lt;/tt&gt;&quot; output.&lt;/p&gt;&lt;/li&gt;
	&lt;li&gt;allow round-robin DNS for the MGS interfaces from a single hostname would avoid the need to specify multiple MGS hostnames on the command-line:
&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;# host mgs-fs1
mgs-fs1 has address 141.193.213.10
mgs-fs1 has address 141.193.213.11
# mount -t mgs-fs1@o2ib:/testfs /lustre/testfs/client
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;This should work for both IPv4 and IPv6 hostname resolution, but requires that &lt;tt&gt;mount.lustre&lt;/tt&gt; and/or &lt;tt&gt;libcfs_str2nid()&lt;/tt&gt; are able to resolve a single name to multiple NIDs.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;All of the &quot;&lt;tt&gt;mount.lustre&lt;/tt&gt;&quot; improvements only shorten the &lt;b&gt;input&lt;/b&gt; name given on the command line.  However, &lt;tt&gt;/proc/mounts&lt;/tt&gt; would still show the full list of MGS NIDs for &lt;tt&gt;df&lt;/tt&gt; and &lt;tt&gt;mount&lt;/tt&gt; output.&lt;/p&gt;

&lt;p&gt;One (possibly controversial) option would be to shorten the command-line displayed in &lt;tt&gt;/proc/mounts&lt;/tt&gt; to only list the NID(s) of the currently-active MGS.  That would keep the command-line down to ~2 NIDs, but would mean that copying the shortened displayed command-line to other nodes would potentially cause them problems if the MGS failed over, because they would only know one set of NIDs.&lt;/p&gt;

&lt;p&gt;Another option would be (in the case of hostnames or round-robin DNS) would be to internally pass the original MGS name as an &quot;MGS display name&quot; as an option the kernel &lt;tt&gt;mount(2)&lt;/tt&gt; command (e.g. &quot;&lt;tt&gt;--mgs-display=mgs-cli1@o2ib&lt;/tt&gt;&quot;).  This would be shown by &lt;tt&gt;/proc/mounts&lt;/tt&gt; and should work equally well for other clients, since they should also be able to resolve the hostname similarly.&lt;/p&gt;</description>
                <environment></environment>
        <key id="75582">LU-16738</key>
            <summary>Improve mount.lustre with many MGS NIDs</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="simmonsja">James A Simmons</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                    </labels>
                <created>Fri, 14 Apr 2023 18:12:42 +0000</created>
                <updated>Sat, 3 Feb 2024 18:51:44 +0000</updated>
                                            <version>Lustre 2.16.0</version>
                    <version>Lustre 2.15.2</version>
                                                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                            <comments>
                            <comment id="398885" author="adilger" created="Mon, 8 Jan 2024 21:22:56 +0000"  >&lt;p&gt;In &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-17186&quot; title=&quot;Replace deprecated gethostby*() calls with get*info() to support resolv ordering&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-17186&quot;&gt;&lt;del&gt;LU-17186&lt;/del&gt;&lt;/a&gt; Jian wrote:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;The &lt;tt&gt;getaddrinfo()&lt;/tt&gt; function allocates and initializes a linked list of &lt;em&gt;addrinfo&lt;/em&gt; structures, one for each network address that matches &lt;em&gt;node&lt;/em&gt; and &lt;em&gt;service&lt;/em&gt;, subject to any restrictions imposed by &lt;em&gt;hints&lt;/em&gt;, and returns a pointer to the start of the list in &lt;em&gt;res&lt;/em&gt;. The items in the linked list are linked by the &lt;em&gt;ai_next&lt;/em&gt; field.&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;
       &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt; getaddrinfo(&lt;span class=&quot;code-keyword&quot;&gt;const&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;char&lt;/span&gt; *node, &lt;span class=&quot;code-keyword&quot;&gt;const&lt;/span&gt; &lt;span class=&quot;code-object&quot;&gt;char&lt;/span&gt; *service,
                       &lt;span class=&quot;code-keyword&quot;&gt;const&lt;/span&gt; struct addrinfo *hints,
                       struct addrinfo **res);

       struct addrinfo {
           &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;              ai_flags;
           &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;              ai_family;
           &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;              ai_socktype;
           &lt;span class=&quot;code-object&quot;&gt;int&lt;/span&gt;              ai_protocol;
           socklen_t        ai_addrlen;
           struct sockaddr *ai_addr;
           &lt;span class=&quot;code-object&quot;&gt;char&lt;/span&gt;            *ai_canonname;
           struct addrinfo *ai_next;
       };
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;&lt;/blockquote&gt;

&lt;p&gt;This paves the way to use this interface to fetch multiple addresses for a single MGS hostname on the &lt;tt&gt;mount.lustre&lt;/tt&gt; command line.  &lt;/p&gt;

&lt;p&gt;I think the other thing that could be done is adding mount option with the &quot;display name&quot; for the MGS in the &lt;tt&gt;/proc/mounts&lt;/tt&gt; output, which is the symbolic name to use for a client mount, even though it is not exactly the list of NIDs actually passed down to the kernel for mounting.  We could have a separate &lt;tt&gt;llite.&lt;em&gt;FSNAME&lt;/em&gt;-*.mount&lt;/tt&gt; parameter that prints the &lt;em&gt;actual&lt;/em&gt; mount command line for debugging if needed, but this wouldn&apos;t make &quot;&lt;tt&gt;df&lt;/tt&gt;&quot; so ugly.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="13182">LU-10391</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="79660">LU-17379</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="75489">LU-16722</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="78355">LU-17186</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                            <subtask id="79660">LU-17379</subtask>
                    </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|i03iz3:</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>