<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoPlainText">It may be related to this issue of using root squashed file system option, here are some edited comments from my colleague who stumbled upon this while chatting with a friend at a CUG:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">" Something I learned last week:  apparently the libmount code from util-linux (used by /bin/mount) will call utimensat() on new mountpoints if access() fails (for example, on root-squashed filesystems).  This is done "just to be sure"
 that the filesystem is really read-only.  This operation can be quite expensive and (anecdotally) may cause huge slowdowns when mounting root-squashed parallel filesystems on thousands of clients.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Here is the relevant code:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">https://github.com/karelzak/util-linux/blame/1ea4e7bd8d9d0f0ef317558c627e6fa069950e8d/libmount/src/utils.c#L222<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">This code has been in util-linux for years.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">It's not clear exactly what the impact is in our environment, but this certainly can't be helping, especially since we've grown the size of the cluster considerably. Mounting GPFS has recently really become a slow and disruptive operation
 – if you try to mount many clients at once, the FS will hang for a considerable period of time.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The timing varies, but here is one example from an isolated mounting operation:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">12:09:11.222513 mount("<gpfs_fs>", "<mount_point>", "gpfs", MS_MGC_VAL, "dev=<gpfs_cluster>"...) = 0 <1.590217><o:p></o:p></p>
<p class="MsoPlainText">12:09:12.812777 access("<mount_point>", W_OK) = -1 EACCES (Permission denied) <0.000022><o:p></o:p></p>
<p class="MsoPlainText">12:09:12.812841 utimensat(AT_FDCWD, "<mount_point>", \{UTIME_NOW, \{93824994378048, 1073741822}}, 0) = -1 EPERM (Operation not permitted) <2.993689><o:p></o:p></p>
<p class="MsoPlainText"><o:p></o:p></p>
<p class="MsoPlainText">Here, the utimensat() took ~3 seconds, almost twice as long as the mount operation! I also suspect it will slow down other clients trying to mount the filesystem since the sgmgr has to process this write attempt to the mountpoint.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">(Hilariously, it still returns the "wrong" answer, because this filesystem is not read-only, just squashed.)<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">As of today, the person who originally brought the issue to my attention at CUG has raised it for discussion on the util-linux mailing list.<o:p></o:p></p>
<p class="MsoPlainText">https://marc.info/?l=util-linux-ng&m=151075932824688&w=2<o:p></o:p></p>
<p class="MsoPlainText">"<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">We ended up putting facls on our mountpoints like such, which hacked around this stupidity:<o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:10.0pt;font-family:"Courier New"">for fs in gpfs_mnt_point ; do<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-size:10.0pt;font-family:"Courier New"">  chmod 1755 $fs<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-size:10.0pt;font-family:"Courier New"">  setfacl -m u:99:rwx $fs  # 99 is the "nobody" uid to which root is mapped--see "mmauth" output<o:p></o:p></span></p>
<p class="MsoPlainText"><span style="font-size:10.0pt;font-family:"Courier New"">done<o:p></o:p></span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Hope that helps,<o:p></o:p></p>
<p class="MsoPlainText">-Bryan<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: gpfsug-discuss-bounces@spectrumscale.org [mailto:gpfsug-discuss-bounces@spectrumscale.org] On Behalf Of Aaron Knister<br>
Sent: Thursday, February 08, 2018 2:23 PM<br>
To: Loic Tortay <tortay@cc.in2p3.fr><br>
Cc: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>
Subject: Re: [gpfsug-discuss] mounts taking longer in 4.2 vs 4.1?</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Note: External Email<o:p></o:p></p>
<p class="MsoPlainText">-------------------------------------------------<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Hi Loic,<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Thank you for that information!<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I have two follow up questions--<o:p></o:p></p>
<p class="MsoPlainText">1. Are you using ccr?<o:p></o:p></p>
<p class="MsoPlainText">2. Do you happen to have mmsdrserv disabled in your environment? (e.g. what's the output of "mmlsconfig mmsdrservPort" on your cluster?).<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-Aaron<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">On Thu, 8 Feb 2018, Loic Tortay wrote:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> On 07/02/2018 22:28, Aaron Knister wrote:<o:p></o:p></p>
<p class="MsoPlainText">>> I noticed something curious after migrating some nodes from 4.1 to 4.2<o:p></o:p></p>
<p class="MsoPlainText">>> which is that mounts now can take foorrreeevverrr. It seems to boil down<o:p></o:p></p>
<p class="MsoPlainText">>> to the point in the mount process where getEFOptions is called.<o:p></o:p></p>
<p class="MsoPlainText">>> <o:p></o:p></p>
<p class="MsoPlainText">>> To highlight the difference--<o:p></o:p></p>
<p class="MsoPlainText">>> <o:p></o:p></p>
<p class="MsoPlainText">> [...]<o:p></o:p></p>
<p class="MsoPlainText">>> <o:p></o:p></p>
<p class="MsoPlainText">> Hello,<o:p></o:p></p>
<p class="MsoPlainText">> I have had this (or a very similar) issue after migrating from 4.1.1.8 to
<o:p></o:p></p>
<p class="MsoPlainText">> 4.2.3.  There are 37 filesystems in our main cluster, which made the problem
<o:p></o:p></p>
<p class="MsoPlainText">> really noticeable.<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> A PMR has been opened.  I have tested the fixes included in 4.2.3.7, (which,
<o:p></o:p></p>
<p class="MsoPlainText">> I'm told, should be released today) actually resolve my problems (APAR
<o:p></o:p></p>
<p class="MsoPlainText">> IJ03192 & IJ03235).<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
<p class="MsoPlainText">> Loïc.<o:p></o:p></p>
<p class="MsoPlainText">> -- <o:p></o:p></p>
<p class="MsoPlainText">> |   Loïc Tortay <<a href="mailto:tortay@cc.in2p3.fr"><span style="color:windowtext;text-decoration:none">tortay@cc.in2p3.fr</span></a>>  -     IN2P3 Computing Centre     |<o:p></o:p></p>
<p class="MsoPlainText">><o:p> </o:p></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this
 email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. The Company, therefore, does not make any guarantees as to the completeness
 or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial
 product.<br>
</font>
</body>
</html>